March 18
On 3/9/24 22:47, Richard (Rikki) Andrew Cattermole wrote:
> On 10/03/2024 10:26 AM, ryuukk_ wrote:
>> If there is a significant build penalty, than i hope it's opt-in, i personally do not use any of the attributes
> 
> It shouldn't be significant.
> 
> It is a minor cost as things go, no reason to start thinking opt-in at this stage.

Really? This proposal requires full semantic analysis of any imported function. It is only minor in certain build setups. (E.g., when the project is compiled in a single invocation.)
March 18
On 18/03/2024 12:12 PM, Timon Gehr wrote:
> On 3/9/24 22:47, Richard (Rikki) Andrew Cattermole wrote:
>> On 10/03/2024 10:26 AM, ryuukk_ wrote:
>>> If there is a significant build penalty, than i hope it's opt-in, i personally do not use any of the attributes
>>
>> It shouldn't be significant.
>>
>> It is a minor cost as things go, no reason to start thinking opt-in at this stage.
> 
> Really? This proposal requires full semantic analysis of any imported function. It is only minor in certain build setups. (E.g., when the project is compiled in a single invocation.)

I am assuming that you generate .di files every time and use that for importing, not the .d files.

These days I'm leaning quite heavily towards projects using .di files for intermediary steps, due to distribution reasons with shared libraries.

It's already impossible to keep bindings to D code up to date manually, I tried pure was a killer on that idea.
March 20
On Monday, 18 March 2024 at 10:30:28 UTC, Richard (Rikki) Andrew Cattermole wrote:
> I am assuming that you generate .di files every time and use that for importing, not the .d files.

Yes, this is one possible mitigation.

The main downside of this is that .di files don't include function bodies, so you lose access to cross-module CTFE. Although I guess we could add a compiler switch to include function bodies in .di files.
April 05

On Thursday, 29 February 2024 at 22:39:43 UTC, Paul Backus wrote:

>

On Thursday, 29 February 2024 at 21:21:12 UTC, Sebastiaan Koppe wrote:

>

What about only doing inference when something fails to compile due to a missing attribute?

This would completely break separate compilation,

Isn't that already broken? See Bugzilla Issue #17541
https://forum.dlang.org/post/gguwkjyiduyxjilyluvf@forum.dlang.org#:~:text=%3A%20Bugzilla%20Issue%20%2317541

It seems inference need to spend more time to find out if some attribute can really be added and not give up early - else there will be always cases where an attribute is expected but was not inferred. Maybe the compiler should even warn, if it is not sure if some attribute is fulfilled or not? Something like: "purity could not be inferred. Please explicitly state if this function is pure or not"
(of course that would require the counterparts of pure, @nogc and @nothrow)

April 05
On Wednesday, 20 March 2024 at 23:59:09 UTC, Paul Backus wrote:
> On Monday, 18 March 2024 at 10:30:28 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> I am assuming that you generate .di files every time and use that for importing, not the .d files.
>
> Yes, this is one possible mitigation.
>
> The main downside of this is that .di files don't include function bodies, so you lose access to cross-module CTFE. Although I guess we could add a compiler switch to include function bodies in .di files.

I would much better like having .di files that don't contain any code (even not for templates) and instead store the template bodies in some intermediary format in another file (of course not an object file, as it need to be possible to create different instances from it, but also not source-code because it should be possible to deliver e.g. a library without sources).
1 2
Next ›   Last »