April 05, 2020 Re: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | 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 Re: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 Re: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 Re: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 Re: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 Re: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 Re: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 OT: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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 Re: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | 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 Re: Request for Comment assert(__ctfe) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stefan Koch | 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? |
Copyright © 1999-2021 by the D Language Foundation