www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.ideas - Explcit impure function attribute

reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
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:
1. 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.
2. Make ` impure` a compiler-recognized AtAttribute.
    This has the downside of being asymmetric: `pure` has no ` `, 
but its inverse ` impure` would have it.
3. 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.
4. ―???―
Jun 24
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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. Making all attributes consistent with using `` `` is a good thing.
Jun 24
parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
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.
Jun 26
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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.
Jun 26
parent reply IchorDev <zxinsworld gmail.com> writes:
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?
Jul 05
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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.
Jul 05