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