February 23, 2021
On Tuesday, 23 February 2021 at 15:49:14 UTC, Stefan Koch wrote:
>
> Yes it would be possible to reuse mixin, but iirc mixins convert non-string expressions to string which would introduce ambiguity, if I special case it __struct, or __type__.

My gut feeling is that it would not be too difficult to understand in practice, but yes, it would require special-casing.

> The restriction is imposed to avoid confusing situations, due to the closeness of the mapping to real compiler entities you cannot finalize the same struct* twice and such things.
> Modifying a __struct after it has been finalized or 'mixed-in' is either useless or a bug.

Actually, now that I think of it, wouldn't the existing CTFE semantics prevent you from doing this anyway?

enum __struct s = someTypeFunction();
auto modify(ref __struct s) { ... }
enum result = modify(s); // Error: can't modify rvalue

Or if you tried to do it inside a type function:

auto someTypeFunction(...) {
    __struct s = ...;
    alias Before = mixin(s); // Error: can't read `s` at compile time
    modify(s);
}
February 23, 2021
On Tuesday, 23 February 2021 at 13:31:00 UTC, Paulo Pinto wrote:
> spends development money getting stuff to work, or just integrate the existing ecosystem and proceed to spend customer's money on actual product development.

It costs very real development money to live with C++ and "getting stuff to work". If anything, D is much more debt-conscious since frontends are shared and you can use the LLVM target for about everything.


February 23, 2021
On Tuesday, 23 February 2021 at 16:10:26 UTC, Paul Backus wrote:
> On Tuesday, 23 February 2021 at 15:49:14 UTC, Stefan Koch wrote:
>> [...]
>
> My gut feeling is that it would not be too difficult to understand in practice, but yes, it would require special-casing.
>
>> [...]
>
> Actually, now that I think of it, wouldn't the existing CTFE semantics prevent you from doing this anyway?
>
> enum __struct s = someTypeFunction();
> auto modify(ref __struct s) { ... }
> enum result = modify(s); // Error: can't modify rvalue
>
> Or if you tried to do it inside a type function:
>
> auto someTypeFunction(...) {
>     __struct s = ...;
>     alias Before = mixin(s); // Error: can't read `s` at compile time
>     modify(s);
> }

... yes you have a point there.

... perhaps I am worrying too much.
February 23, 2021
On Tuesday, 23 February 2021 at 15:13:18 UTC, Stefan Koch wrote:
> On Tuesday, 23 February 2021 at 15:04:46 UTC, IGotD- wrote:
>> On Tuesday, 23 February 2021 at 13:58:34 UTC, Stefan Koch wrote:
>>>
>>> If they play their cards right and integrate their meta-info properly with constexpr it's going to beat D.
>>
>> Can you explain further why it is going to beat D (I assume in terms of functionality, not aesthetics).
>
> Because the conversion to reflection values meta::info or whatever it was called happens inside the compiler.
> It's not shackled to templates.
>
> And therefore they can have very fast generation of these without inuring recursive evluate-semantic() function calls.

Actually I take that back.
I should have looked more closely.
They have polymorphic expressions (changing the static type) which means they can only use those within polymorphic contexts ... which does shackle them to templates again.
February 23, 2021
On Monday, 22 February 2021 at 16:27:49 UTC, Andrei Alexandrescu wrote:
> Of possible interest:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2320r0.pdf


> void f(... [:range_of_types:] ...args)

This seems like it could provide a more intuitive intellisense display for things like std::make_shared, but without proper parameter names. Unless this provides a path to including parameter names, I don't see how it's better than <Args&&...>.
1 2 3 4
Next ›   Last »