On 01/03/2024 2:46 AM, Dukc wrote:
snip

Dukc makes a good point, being able to override inference is important when it fails to work with other functions or scenarios (such as globally set attributes).

We will need to consider adding the opposite of a given attribute, to maximize the possibility of inference not interfering with peoples code negatively.

On Thursday, 29 February 2024 at 14:03:30 UTC, Richard (Rikki) Andrew Cattermole wrote:
> We will need to consider adding the opposite of a given attribute, to maximize the possibility of inference not interfering with peoples code negatively.

I agree that adding opposites for the remaining function attributes without them is a good idea, but it isn't strictly necessary. Even if you only have a single @noinfer attribute, you can simulate "impure" and "@gc" like this:

    @noinfer @safe nothrow @nogc
    void inferImpure() {}

    @noinfer @safe pure nothrow
    void inferGC() {}

    // Will never be pure or @nogc
    void example()
    {
        inferImpure();
        inferGC();

        // etc.
    }

The main benefit of @noinfer (compared to impure/@gc) is that it does not require adding a new reserved word. Since one of the main benefits of universal inference is that it works with existing code, I plan to propose it for inclusion in the base language edition, and that means avoiding breaking language changes.

The main difficulty with this is it requires the compiler to compile all the functions in the "header" files. This is a significant performance penalty. That is why the current scheme only infers for functions that the compiler must compile anyway, such as templates and auto functions.

I'm not necessarilly saying "no", just that everyone should be aware of this.

On 10/03/2024 9:07 AM, Walter Bright wrote:
> The main difficulty with this is it requires the compiler to compile all the functions in the "header" files. This is a significant performance penalty. That is why the current scheme only infers for functions that the compiler must compile anyway, such as templates and auto functions.
> 
> I'm not necessarilly saying "no", just that everyone should be aware of this.

There is some concern with multi-step builds yes.

However we do have a solution that while it isn't ready for use today, it could be made ready once a preview switch has been implemented.

The .di generator.

It could be a while until we could turn the preview switch on, perhaps two or three editions.

A bit of an adjustment yes, but the benefit means no more attribute soup to write for non-virtual code so I expect it to be worth it!

On Saturday, 9 March 2024 at 20:33:35 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 10/03/2024 9:07 AM, Walter Bright wrote:
>> The main difficulty with this is it requires the compiler to compile all the functions in the "header" files. This is a significant performance penalty. That is why the current scheme only infers for functions that the compiler must compile anyway, such as templates and auto functions.
>> 
>> I'm not necessarilly saying "no", just that everyone should be aware of this.
>
> There is some concern with multi-step builds yes.
>
> However we do have a solution that while it isn't ready for use today, it could be made ready once a preview switch has been implemented.
>
> The .di generator.
>
> It could be a while until we could turn the preview switch on, perhaps two or three editions.
>
> A bit of an adjustment yes, but the benefit means no more attribute soup to write for non-virtual code so I expect it to be worth it!

If there is a significant build penalty, than i hope it's opt-in, i personally do not use any of the attributes

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.