Explcit impure function attribute

Jun 24

Quirin Schroll

Jun 24

Richard (Rikki) Andrew Cattermole

Jun 26

Quirin Schroll

Jun 26

Richard (Rikki) Andrew Cattermole

Jul 05

IchorDev

Jul 05

Richard (Rikki) Andrew Cattermole

June 24

Explcit impure function attribute

Posted by Quirin Schroll

Permalink

Quirin Schroll

Permalink

As I’m working getting the @gc function attribute into D, the last remaining covariant attribute without contravariant inverse will be pure. The biggest question will not be how useful it is because its use will be exactly like that of other contravariant attributes (@system, throw, and @gc), no, the biggest question is syntax.

What are your preferences?

A few inspirations:

Make impure a hard keyword, so pure and impure falls into the same syntactical category as throw and nothrow.
This has the downside of breaking code that has identifiers named impure. I’d guess those would be rare, though.
Make @impure a compiler-recognized AtAttribute.
This has the downside of being asymmetric: pure has no @, but its inverse @impure would have it.
Make impure a contextual keyword, i.e. a compiler-recognized identifier with special meaning in certain places, similar to body.
This has the downside that it breaks very specific code (e.g. int function() impure) and that it uses contextual keywords which Walter really doesn’t like. This option is interesting for the base language when Option 1 is pursued in the next Edition.
―???―

On Monday, 24 June 2024 at 16:47:06 UTC, Richard (Rikki) Andrew Cattermole wrote:

On 25/06/2024 4:38 AM, Quirin Schroll wrote:

Make @impure a compiler-recognized AtAttribute. This has the downside of being asymmetric: pure has no @, but its inverse @impure would have it.

So add it.

Deprecate, then remove without @ in newer editions.

So, you favor (effectively) adding @impure, and adding @pure as an alias for pure, while deprecating pure. Did I understand that correctly?

Making all attributes consistent with using @ is a good thing.

There are still throw and nothrow. If I had to lay a bet on it, I’d say they don’t go anywhere. The value of replacing them with something with @ is negligible.

On 27/06/2024 5:35 AM, Quirin Schroll wrote: > On Monday, 24 June 2024 at 16:47:06 UTC, Richard (Rikki) Andrew Cattermole wrote: >> On 25/06/2024 4:38 AM, Quirin Schroll wrote: >>> Make `@impure` a compiler-recognized AtAttribute. This has the downside of being asymmetric: `pure` has no `@`, but its inverse `@impure` would have it. >> >> So add it. >> >> Deprecate, then remove without ``@`` in newer editions. > > So, you favor (effectively) adding `@impure`, and adding `@pure` as an alias for `pure`, while deprecating `pure`. Did I understand that correctly? Yes. Get all the attributes to be the same, clean it up! >> Making all attributes consistent with using ``@`` is a good thing. > > There are still `throw` and `nothrow`. If I had to lay a bet on it, I’d say they don’t go anywhere. The value of replacing _them_ with something with `@` is negligible. They'll both be going away at some point in favor of a throws set, to allow for value type exceptions. No other way to get the sumtype style exceptions working and there is significant desire by core developers for it.

It might be a bit of a hassle to update, but since `pure` is a keyword right now it'd be easy to just find-and-replace it with `@pure`, so I'm all for `@pure`, `@impure`, and no more `pure` keyword. On Wednesday, 26 June 2024 at 17:51:46 UTC, Richard (Rikki) Andrew Cattermole wrote: > there is significant desire by core developers for it. So Phobos 3 will use SumType exceptions out of the gate?

On 05/07/2024 11:38 PM, IchorDev wrote: > On Wednesday, 26 June 2024 at 17:51:46 UTC, Richard (Rikki) Andrew Cattermole wrote: > > there is significant desire by core developers for it. > > So Phobos 3 will use SumType exceptions out of the gate? I don't think it would be std.sumtype based. I do wish it was sumtype based however, but until that is in the language value type exceptions can't go in so we're a tad blocked atm.

Forums