Jump to page: 1 2 3
Thread overview
February 28

Description

Currently, function attributes and function parameter attributes are only inferred by the D compiler for certain kinds of functions. This DIP idea proposes that such inference be extended to all non-overridable functions with bodies.

The primary goal of universal inference is to solve D's "attribute soup" problem without breaking compatibility with existing code. Compatibility with existing code makes universal inference a better solution to this problem than "@safe by default," "nothrow by default," and other similar proposals.

Overridable functions (that is, non-final virtual functions) are excluded from universal inference because their bodies may be replaced at runtime.

For cases where attribute inference is not desired, an opt-out mechanism will be provided.

Currently, .di files generated by the compiler do not include inferred function attributes. This will have to change.

Related Links

February 29

On Wednesday, 28 February 2024 at 17:18:04 UTC, Paul Backus wrote:

>

[snip]

I do not personally care whether inference is on or off by default. It's easy to toggle when I want anyway. On balance maybe I prefer it being off by default, simply because of backwards compatibility.

Still, this is a worthwhile direction to pursue. I'm sometimes annoyed that I can't specify a return type for a function and still turn attribute inference on (without making it a template), or that I can't turn attribute inference off for templates or function literals. If the proposal will address those, I might well support it.

I feel this proposal is orthogonal to the question of attribute defaults per se - we will still want to debate the defaults regardless of inference - but it will certainly take pressure off from that question. Especially if this dip will include an ability to turn any function attribute either on, off, or to be inferred. In that case it'll be trivial for anyone to add their favorite default attributes on top of each module, and selectively override those as needed. Something like:

module example;

@safe:
@autoinpure:
@autonothrow:
@gc:

pure int failsCompilationIfImpure(int) => // ..

@trusted int canBeUnsafeInternally(int) => // ...

@autonogc T sometimesNogcTemplate(T)(int) => // ...
March 01
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.
February 29

On Wednesday, 28 February 2024 at 17:18:04 UTC, Paul Backus wrote:

>

[...]

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

Say a nothrow function calling a non one. Compiler detects it, but before erroring out checks if the function is implicitly nothrow and then continues accordingly.

Opting out can be done by setting incompatible attributes. E.g. if I explicitly mark a function as system, no amount of inference will enable it to be called from safe.

That way you can have almost no attributes anywhere except for e.g. @safe on main and get safety everywhere or an error

February 29

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

>

On Wednesday, 28 February 2024 at 17:18:04 UTC, Paul Backus wrote:

>

[...]

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

This would completely break separate compilation, but it would still be a bad idea even if it didn't. Having the attributes of a function depend on the code that calls it violates modularity and creates all kinds of opportunities for "spooky action at a distance."

Also as far as I can tell there is literally zero upside to this approach compared to the original version. What is all of this additional complexity supposed to be buying us?

February 29
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.
March 09
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.
March 10
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!
March 09
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
March 10
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.
« First   ‹ Prev
1 2 3