April 05, 2020
On Sunday, 5 April 2020 at 20:54:03 UTC, Meta wrote:
> On Sunday, 5 April 2020 at 20:31:15 UTC, Timon Gehr wrote:
>> On 05.04.20 14:11, Stefan Koch wrote:
>>> [...]
>>
>> Make sure it works with `in` contracts:
>>
>> string generateMixin(string[] params)in{
>>     assert(__ctfe);
>> }do{
>>     .... more code ....
>> }
>>
>> (The plain assertion slightly hurts my eyes, because if it fails, that failure would be attributable to the GenerateMixin function, whereas with the `in` contract it is clear that the caller is at fault.)
>
> We likely get the shorthand version for free as well:
> string generateMixin(...)
> in(__ctfe)
> {
>    ...
> }

No. the in contract was already a pain in the butt.
April 05, 2020
On Sunday, 5 April 2020 at 22:12:02 UTC, Stefan Koch wrote:
> On Sunday, 5 April 2020 at 20:54:03 UTC, Meta wrote:
>> We likely get the shorthand version for free as well:
>> string generateMixin(...)
>> in(__ctfe)
>> {
>>    ...
>> }
>
> No. the in contract was already a pain in the butt.

That IS an in contract. idk about the implementation but from the user level this is identical to in { assert(__ctfe);}
April 06, 2020
On 06.04.20 00:12, Stefan Koch wrote:
> On Sunday, 5 April 2020 at 20:54:03 UTC, Meta wrote:
>> On Sunday, 5 April 2020 at 20:31:15 UTC, Timon Gehr wrote:
>>> On 05.04.20 14:11, Stefan Koch wrote:
>>>> [...]
>>>
>>> Make sure it works with `in` contracts:
>>>
>>> string generateMixin(string[] params)in{
>>>     assert(__ctfe);
>>> }do{
>>>     .... more code ....
>>> }
>>>
>>> (The plain assertion slightly hurts my eyes, because if it fails, that failure would be attributable to the GenerateMixin function, whereas with the `in` contract it is clear that the caller is at fault.)
>>
>> We likely get the shorthand version for free as well:
>> string generateMixin(...)
>> in(__ctfe)
>> {
>>    ...
>> }
> 
> No. the in contract was already a pain in the butt.

I don't understand how you would implement it in a way where the above does not work. Have you tested it? I am literally rewriting `in(__ctfe)` to `in{ assert(__ctfe); }` in the parser:

https://github.com/dlang/dmd/blob/master/src/dmd/parse.d#L5060
April 06, 2020
On Monday, 6 April 2020 at 01:28:19 UTC, Timon Gehr wrote:
>
> I don't understand how you would implement it in a way where the above does not work. Have you tested it? I am literally rewriting `in(__ctfe)` to `in{ assert(__ctfe); }` in the parser:
>
> https://github.com/dlang/dmd/blob/master/src/dmd/parse.d#L5060

I see. Well in that case it'll work out of the box.
Although it does make me shudder to change the Tree in the parser in such a way.
When was this merged?
April 06, 2020
On 06.04.20 04:25, Stefan Koch wrote:
> On Monday, 6 April 2020 at 01:28:19 UTC, Timon Gehr wrote:
>>
>> I don't understand how you would implement it in a way where the above does not work. Have you tested it? I am literally rewriting `in(__ctfe)` to `in{ assert(__ctfe); }` in the parser:
>>
>> https://github.com/dlang/dmd/blob/master/src/dmd/parse.d#L5060
> 
> I see. Well in that case it'll work out of the box.
> Although it does make me shudder to change the Tree in the parser in such a way.

For no reason at all. It's the appropriate place to expand simple short-hand notation, e.g., see template functions.

It's just good engineering. Let's consider the evidence:

What you expected to be the case:

- `in(expr)` is a special kind of construct in the AST, burdening the entire compiler code base from frontend to backend.
- `in{ assert(__ctfe); }` and `in(__ctfe)` have diverging behavior, a unfortunate development caused by butt pain.

What was actually the case:

- `in(expr)` is simple shorthand notation and is treated by the compiler precisely like `in{ assert(__ctfe); }`
- `in(__ctfe)` works precisely like `in{ assert(__ctfe); }` even after the latter has been special-cased.

You might want to recalibrate your guts. :P

> When was this merged?

Just when it should have been, right after the corresponding DIP was accepted.
April 06, 2020
On Monday, 6 April 2020 at 03:11:41 UTC, Timon Gehr wrote:
> On 06.04.20 04:25, Stefan Koch wrote:
>> [...]
>
> For no reason at all. It's the appropriate place to expand simple short-hand notation, e.g., see template functions.
>
> [...]

I don't mind the what. I just mind the when. But it's not a big deal either way. I would have done it in sema.
April 06, 2020
On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
> Hi Guys,
>
> I am currently working on speeding up dmd. In the presence of templates and ctfe.
> and one thing that stood out is that we do codegen for symbols which are never used.
> (and hopefully eliminated by a smart linker but eh ...)
>
> [...]

Wouldn't it be easier to skip codegen for private functions that are never called from non CTFE contexts?
April 06, 2020
On Monday, 6 April 2020 at 07:33:19 UTC, Stefan Koch wrote:
> On Monday, 6 April 2020 at 03:11:41 UTC, Timon Gehr wrote:
>> On 06.04.20 04:25, Stefan Koch wrote:
>>> [...]
>>
>> For no reason at all. It's the appropriate place to expand simple short-hand notation, e.g., see template functions.
>>
>> [...]
>
> I don't mind the what. I just mind the when. But it's not a big deal either way. I would have done it in sema.

Offtopic.
This triggers me, so a quick response: the tree rewriting that happens all over the place in the compiler frontend is very problematic with anything that has to report back to the user and more: debug location information, error reporting, coverage reporting, syntax highlighting, source formatting, etc., etc. [*]

-Johan

[*] As an example, even the harmless looking replacement of __FILE__ by the parser, turns out to be very problematic for LDC for deterministically generating symbol names (linking) when combined with crossmodule inlining :(

April 06, 2020
On Monday, 6 April 2020 at 10:14:24 UTC, Atila Neves wrote:
> On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I am currently working on speeding up dmd. In the presence of templates and ctfe.
>> and one thing that stood out is that we do codegen for symbols which are never used.
>> (and hopefully eliminated by a smart linker but eh ...)
>>
>> [...]
>
> Wouldn't it be easier to skip codegen for private functions that are never called from non CTFE contexts?

Easier from the user-perspective yes.
From the compiler perspective,
That's another step which may take quite a while to do correctly.
The easy thing would be (Essentially an (N*M) loop over all calls and functions), which I doubt will help compile-times much.

For now assert(__ctfe); enables people to manually mark their ctfe-only, functions.
April 06, 2020
On Monday, 6 April 2020 at 13:41:52 UTC, Stefan Koch wrote:
> On Monday, 6 April 2020 at 10:14:24 UTC, Atila Neves wrote:
>> On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
>>> [...]
>>
>> Wouldn't it be easier to skip codegen for private functions that are never called from non CTFE contexts?
>
> Easier from the user-perspective yes.
> From the compiler perspective,
> That's another step which may take quite a while to do correctly.
> The easy thing would be (Essentially an (N*M) loop over all calls and functions),

Where N and M are all calls and private functions in one module, not all code in a project.

> For now assert(__ctfe); enables people to manually mark their ctfe-only, functions.

What about `in(__ctfe)` instead?