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?

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. :)

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

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

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

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

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

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.

"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. 

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