www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - DIP64 - Regarding 'pure' and 'nothrow'

reply "Aerolite" <email address.com> writes:
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?
Aug 27 2014
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
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 bothers the heck outta my OCD. :)
Aug 27 2014
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Aug 27 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
I'd be more convinced if the following statements were false:
1. Writing an automated upgrade tool is difficult
2. The compiler would have no way of knowing what  nothrow means
Aug 27 2014
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 27 August 2014 at 19:42:40 UTC, Brian Schott wrote:

 I'd be more convinced if the following statements were false:
 1. Writing an automated upgrade tool is difficult
 2. The compiler would have no way of knowing what  nothrow means


Oh, there's no question that having an automated tool improves 
the situation, but given how Walter seems to think with regards 
to stuff like this, I'd be surprised if he thought that an 
automated tool made it acceptable. Even if it's easy to fix, it's 
still breaking code. He freaks out if all folks have to change is 
a compiler switch. It's always hard to convince Walter that a 
breaking change is acceptable or desirable, and when all you're 
doing is fixing aesthetics, it's pratically a guarantee that he 
won't be in favor of it. He values avoiding code breakage far, 
far more than he values aesthetics or consistency, and now that D 
has been around for as long as it has, Andrei tends to agree with 
him, whereas it used to be that you could convince Andrei that a 
change was worth it a lot more easily. So, I'd be very surprised 
if either of them could be convinced that this was worth it.

Personally, I would like it if the situation were more 
consistent, but I don't think that the proposal really fixes 
that. It might improve it, but we're stuck with inconsistencies 
regardless, so I don't see much point in changing it. The way 
that it could have been done "right" IMHO was if we'd never 
introduced   for anything but UDAs and just used keywords for all 
of the attributes, but it's too late for than now.

- Jonathan M Davis
Aug 27 2014
parent reply "Brian Schott" <briancschott gmail.com> writes:
It would be nice if we could at least allow both "nothrow" and 
" nothrow". Because "nothrow" is already a keyword there's no 
possibility of a UDA overriding it. This would at least give 
people the option of making their code look nicer.

The "delete" keyword is deprecated[1] and making that decision 
never broke any code.

[1] http://dlang.org/deprecate.html#delete
Aug 27 2014
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, 27 August 2014 at 20:17:11 UTC, Brian Schott wrote:

 The "delete" keyword is deprecated[1] and making that decision 
 never broke any code.

 [1] http://dlang.org/deprecate.html#delete


LOL. Yeah, we've broken code before, and Walter can be talked 
into it, but it's hard, and it's only getting harder. It helps 
considerably if Andrei can be convinced, though that's not easy 
either. But regardless, anything that's essentially an aesthetic 
improvement will almost certainly get rejected. At this point, it 
almost has to be something that outright gets rid of bugs (like 
eliminating implicit fallthrough in switch statements). And 
delete does fall in that category, because it's an  safe issue. 
It's also something that was decide years ago rather than 
recently.

I can definitely understand why you want to make the changes in 
DIP 64, but you're fighting an uphill battle given that it's 
essentially an aesthetic improvement.

- Jonathan M Davis
Aug 27 2014
prev sibling next sibling parent reply "Aerolite" <email address.com> writes:
On Wednesday, 27 August 2014 at 20:17:11 UTC, Brian Schott wrote:

 It would be nice if we could at least allow both "nothrow" and 
 " nothrow". Because "nothrow" is already a keyword there's no 
 possibility of a UDA overriding it. This would at least give 
 people the option of making their code look nicer.


So no chance even of this? Make it an either/or situation, which
would prevent code-breakage but also encourage  -style usage as
developers would presumably try and maintain consistency?
Admittedly I haven't looked at the compiler source-code, but
surely its infrastructure wouldn't make this prohibitively hard
to do?

I wouldn't mind taking a crack at it myself if it's something
that can be done without too much hassle.
Aug 28 2014
parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Thu, 28 Aug 2014 11:50:48 +0000
Aerolite via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 So no chance even of this?


already done: https://issues.dlang.org/show_bug.cgi?id=3D13388
Aug 28 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Brian Schott"  wrote in message 
news:pbfgiwaxsdxdxetpihzb forum.dlang.org...


 The "delete" keyword is deprecated[1] and making that decision never broke 
 any code.

 [1] http://dlang.org/deprecate.html#delete


If you look at the table up the top, delete hasn't actually been deprecated 
yet.  If and when this will actually happen is uncertain.
Aug 28 2014
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 28 August 2014 at 15:01:58 UTC, Daniel Murphy wrote:

 "Brian Schott"  wrote in message 
 news:pbfgiwaxsdxdxetpihzb forum.dlang.org...


 The "delete" keyword is deprecated[1] and making that decision 
 never broke any code.

 [1] http://dlang.org/deprecate.html#delete


 If you look at the table up the top, delete hasn't actually 
 been deprecated yet.  If and when this will actually happen is 
 uncertain.


AFAIK, the only reason that it's not deprecated is that no one 
has bothered to make the change (and you didn't want to deprecate 
it when you went through all  of those and updated their status a 
while back). Andrei has stated on multiple occasions that it's 
going, and I think that Walter has said the same. Arguably, it 
should have been deprecated ages ago. The only good argument I 
see for keeping it around is that we don't have the custom 
allocators yet, so it's royal pain for anyone to construct 
classes on the malloc heap instead of on the GC heap (since using 
emplace to do it is non-trivial), and anyone who's using delete 
and really doesn't want to wait for the GC to collect the memory 
doesn't have an easy alternative at the moment.

- Jonathan M Davis
Aug 28 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan M Davis"  wrote in message 
news:xjmfhegvanqdivhbtlpp forum.dlang.org...


 AFAIK, the only reason that it's not deprecated is that no one has 
 bothered to make the change (and you didn't want to deprecate it when you 
 went through all  of those and updated their status a while back). Andrei 
 has stated on multiple occasions that it's going, and I think that Walter 
 has said the same. Arguably, it should have been deprecated ages ago. The 
 only good argument I see for keeping it around is that we don't have the 
 custom allocators yet, so it's royal pain for anyone to construct classes 
 on the malloc heap instead of on the GC heap (since using emplace to do it 
 is non-trivial), and anyone who's using delete and really doesn't want to 
 wait for the GC to collect the memory doesn't have an easy alternative at 
 the moment.


Until it actually gets merged in, nothing is certain.  delete is not 
particularly dangerous now that we have  safe working, and it might be nice 
to have on non-GC platforms.  Anyway, that's a discussion for when somebody 
actually tries to get rid of it.
Aug 28 2014
prev sibling next sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 27 Aug 2014 20:17:10 +0000
Brian Schott via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:


 It would be nice if we could at least allow both "nothrow" and=20
 " nothrow".


i believe this patch should be trivial. i'll try to look at this issue
closer and maybe produce another useless patch to rot in bugzilla. ;-)
Aug 27 2014
prev sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 27 Aug 2014 20:17:10 +0000
Brian Schott via Digitalmars-d-learn
<digitalmars-d-learn puremagic.com> wrote:


 It would be nice if we could at least allow both "nothrow" and=20
 " nothrow".


here it is, another useless patch:
https://issues.dlang.org/show_bug.cgi?id=3D13388

i'm sure that it will never be accepted in mainline, so i don't bother
attaching any unittests. just believe me: it works. ;-)
Aug 28 2014
prev sibling parent ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Wed, 27 Aug 2014 13:49:47 +0000
Aerolite via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 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.


we can also turn 'const' to ' const' and this will end annoying
confusion between `const T foo ();` and `const(T) foo ();`.

but it's fun to see confused people, so i'm against it. ;-)
Aug 27 2014