DIP64 - Regarding 'pure' and 'nothrow'

Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Wed Aug 27 12:31:05 PDT 2014


On Wednesday, 27 August 2014 at 13:49:48 UTC, Aerolite wrote:
> Hey all,
>
> I just read the wiki article on DIP64 -
> http://wiki.dlang.org/DIP64
>
> The discrepancy between the annotation-style attributes such as
> '@safe', '@property', etc and the keyword attributes 'pure' and
> 'nothrow' has always really bugged me ever since I started using
> D.
>
> How likely is it that DIP64 will be accepted and implemented? 
> Or,
> more specifically, how much does this discrepancy bother others,
> including Walter and Andrei? Or is the author of this DIP wrong
> in his assessment that 'pure' and 'nothrow' are in fact standard
> attributes?

I expect that the odds of it being accepted are very low. It 
would add no technical value. All it does is try and make things 
cleaner visually for programmers, and it would break existing 
code. So, it's exactly the sort of thing that Walter and Andrei 
are likely to be against. At this point, they'll shoot down 
pretty much any request at changing a function name in an attempt 
to improve it precisely because the benefit is minimal, and it 
breaks code. DIP64 is looking to rename stuff in the language, 
but I expect that they'll view it pretty much the same way.

And yeah, it kind of sucks that they're inconsistent, but it's 
not really possible to make them consistent. We can't make them 
all keywords, since that would break too much and rob us of yet 
more possible symbol names, and trying to put @ on them would 
then pretty much putting @ on all attributes - including stuff 
like @public and @static - otherwise, it's still not consistent. 
And then we'd get complaints about it being inconsistent with 
other languages and people's expectations. So yeah, it would have 
been nice if some of the @ attributes had been keywords up front 
so that they'd be consistent, but that ship has long since 
sailed. So, since we can't really be consistent at this point, 
why change it? It would just be break code and make people mad. 
At this point, breaking changes need to provide more value than 
aesthetic appeal.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list