On Tuesday, 27 January 2015 at 01:49:41 UTC, Walter Bright wrote:
> On 1/26/2015 5:45 PM, uri wrote:
>> I get the impression it will never be finished because too many are afraid of
>> important breaking changes that seem necessary to get through the last 5%-10% of
>> D2.
>
> Half want breaking changes, the other half wants stability.

I don't know if 'dfix' will be everything I hope it would be, but I would place my bets on it (not that I have much to bet). I think Go has shown decisive leadership on this aspect of language design and maintenance, and I haven't yet heard any negative reports about 'gofix'. If 'dfix' can't work, for some reason I haven't thought of, then somebody just needs to write a big article justifying D's peculiarities, explaining all the tradeoffs, and why the final decisions were made. Then all newcomers can be referred to those articles. But I suspect the reason these issues keep coming up is that they're still alive. I see 'dfix' as a potential win-win, opening up huge possibilities for issues previously thought out-of-the-question.

What's keeping you from committing to 'dfix' as the way to solve issues like the one in this thread?

On Mon, 26 Jan 2015 17:07:26 +0000
Nick Treleaven via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > In fact, priore to this, @safe,
> > @trusted, @system, and @property were the_only_  function
> > attributes with @ on them.
>
> There's also @disable and more recently, @nogc.

You're right. I forgot about those two. But it's still the case that the number of function attributes that don't have @ on them is _far_ greater than the number of those that do.

- Jonathan M Davis

On Tuesday, 27 January 2015 at 01:31:07 UTC, Jonathan Marler wrote:
> Yes you're right it adds more inconsistency (sorry what I said was wrong).  However, no matter what solution you choose you have to choose one of two evils.  Either add inconsistency or break code.  There's no way around it.  If you ADD another way to write the attributes that looks better, you've created more "inconsistency".  If you REPLACE the existing way to write attributes, you've now broken code.

The third way is to do nothing, and live with the existing inconsistency. It's not a bad choice, considering.

> So again, I was suggesting one way of implementing my proposal which was to add an inconsistency, but you could implement it another way but you would have to break code.  Do you have a solution that doesn't do either?  I think if you try to find one, you'll see that I'm right in saying you're going to have to choose one or the other.

I already suggested the best solution I could come up with: break code in the most benign possible manner, using a compiler-integrated 'dfix' experience. BTW, I'm glad you agree with me about the ugliness of the @ sign. Even with dfix, the decision could still be made to have everything use @'s, which would be a solution to the consistency problem, but I would only welcome it grudgingly. Good looking code is important to me, and @ is *not* where that's @, so to say. :-)

On 1/26/2015 6:15 PM, Zach the Mystic wrote:
> What's keeping you from committing to 'dfix' as the way to solve issues like the
> one in this thread?

Inertia of people being reluctant to use it. It's still work for people to use, it's not part of their build process.

On Tuesday, 27 January 2015 at 02:30:12 UTC, Zach the Mystic wrote:
> On Tuesday, 27 January 2015 at 01:31:07 UTC, Jonathan Marler wrote:
>> Yes you're right it adds more inconsistency (sorry what I said was wrong).  However, no matter what solution you choose you have to choose one of two evils.  Either add inconsistency or break code.  There's no way around it.  If you ADD another way to write the attributes that looks better, you've created more "inconsistency".  If you REPLACE the existing way to write attributes, you've now broken code.
>
> The third way is to do nothing, and live with the existing inconsistency. It's not a bad choice, considering.
>
>> So again, I was suggesting one way of implementing my proposal which was to add an inconsistency, but you could implement it another way but you would have to break code.  Do you have a solution that doesn't do either?  I think if you try to find one, you'll see that I'm right in saying you're going to have to choose one or the other.
>
> I already suggested the best solution I could come up with: break code in the most benign possible manner, using a compiler-integrated 'dfix' experience. BTW, I'm glad you agree with me about the ugliness of the @ sign. Even with dfix, the decision could still be made to have everything use @'s, which would be a solution to the consistency problem, but I would only welcome it grudgingly. Good looking code is important to me, and @ is *not* where that's @, so to say. :-)

Yes doing nothing is the other option :)  I'm kinda bummed we are in this situation in the first place.  If we had a consistent design in the first place it would have saved all this trouble.  Now we can:

1. Live with it
2. Break code
3. Create inconsistency

I believe my proposal is how it should have been designed in the first place (allow identifiers to be function attributes), but not the only way to fix it is to choose 2 or 3.  I don't like either option but I feel like the community is more accepting of option 3 with a deprecation of the old methods.

The problem with doing nothing is these discussions are likely never going to end.  Someone will always bring up this issue and people are going to waste time forever debating what should be done.  Although I think it was you who suggested that we could simply document why it is the way it is, and that would help.  Anyway, thanks for considering my proposal, I know you had to read a lot and you don't think it's a good idea but that's what these forums are for.

On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote:
> On 1/26/2015 6:15 PM, Zach the Mystic wrote:
>> What's keeping you from committing to 'dfix' as the way to solve issues like the
>> one in this thread?
>
> Inertia of people being reluctant to use it. It's still work for people to use, it's not part of their build process.

What about compiler integration? I'm talking about fundamental language changes. Why would people use it if it didn't have official backing and wasn't part of the compiler package? In this post:

http://forum.dlang.org/post/uimpnhiweuitnnbeqshu@forum.dlang.org

... I said: 'For example, let's say dfix is included with the compiler package.
Now you get an error, saying: "Error: `@nogc` is no longer
accepted, but can be automatically replaced with `nogc`. Run dfix
on this file? (y/n)"... or whatever is deemed the secure approach
to this feature.'

That's what I mean by "commiting to dfix."

On Tuesday, 27 January 2015 at 03:25:59 UTC, Zach the Mystic wrote:
> On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright wrote:
>> On 1/26/2015 6:15 PM, Zach the Mystic wrote:
>>> What's keeping you from committing to 'dfix' as the way to solve issues like the
>>> one in this thread?
>>
>> Inertia of people being reluctant to use it. It's still work for people to use, it's not part of their build process.
>
> What about compiler integration? I'm talking about fundamental language changes. Why would people use it if it didn't have official backing and wasn't part of the compiler package? In this post:
>
> http://forum.dlang.org/post/uimpnhiweuitnnbeqshu@forum.dlang.org
>
> ... I said: 'For example, let's say dfix is included with the compiler package.
> Now you get an error, saying: "Error: `@nogc` is no longer
> accepted, but can be automatically replaced with `nogc`. Run dfix
> on this file? (y/n)"... or whatever is deemed the secure approach
> to this feature.'
>
> That's what I mean by "commiting to dfix."

This has come up before. I believe if was at DConf 2014 that Walter answered this question. If I remember, the gist was that Walter didn't like the idea that the compiler could rewrite a user's code, he seemed kinda "creeped" out to think that a compiler would do this.  Then someone suggested the compiler could generate some type of awk expression that the programmer could run to modify the code.  Anyway, just relaying what I remember.

IMO, if the rewrite tool was done well it could be a benefit.  I think a preview of the changes would be a great feature.  But I also understand Walter's point.

On Tuesday, 27 January 2015 at 03:33:15 UTC, Jonathan Marler wrote:
> This has come up before. I believe if was at DConf 2014 that Walter answered this question. If I remember, the gist was that Walter didn't like the idea that the compiler could rewrite a user's code, he seemed kinda "creeped" out to think that a compiler would do this.  Then someone suggested the compiler could generate some type of awk expression that the programmer could run to modify the code.  Anyway, just relaying what I remember.

It's only creepy if it doesn't work. And the compiler doesn't need to change the code itself - it merely needs to tell you exactly what to do to fix it.

I've thought about this some more. The way I would do it is have the compiler store all files which need to be fixed. Output the list in another file of a different type. Have dfix be able to read that file and automatically fix all files listed. Or just generate a D script to do just that (no need for a whole different file format. Literally just output "dfix.d", which has all the filenames built right into the script, and tell the user to 'dmd -run dfix.d'. Now you have a very clear intermediate step between compilation and user-activated step.

On 1/26/15 5:32 PM, Mike wrote:
> The future benefits of fixing this kind of crap, are huge.

IMHO this is myopic. We have much larger issues with e.g. safety, shared, and the core threading library, than syntactic minutia. All of this changing what works has its value, but that pales in comparison. Yes, a light bulb can be bright, but it pales when set against the sun. Context, perspective, vision - that's what matters now. -- Andrei

On Tuesday, 27 January 2015 at 03:54:09 UTC, Zach the Mystic wrote:
> On Tuesday, 27 January 2015 at 03:33:15 UTC, Jonathan Marler wrote:
>> This has come up before. I believe if was at DConf 2014 that Walter answered this question. If I remember, the gist was that Walter didn't like the idea that the compiler could rewrite a user's code, he seemed kinda "creeped" out to think that a compiler would do this.  Then someone suggested the compiler could generate some type of awk expression that the programmer could run to modify the code.  Anyway, just relaying what I remember.
>
> It's only creepy if it doesn't work. And the compiler doesn't need to change the code itself - it merely needs to tell you exactly what to do to fix it.
>
> I've thought about this some more. The way I would do it is have the compiler store all files which need to be fixed. Output the list in another file of a different type. Have dfix be able to read that file and automatically fix all files listed. Or just generate a D script to do just that (no need for a whole different file format. Literally just output "dfix.d", which has all the filenames built right into the script, and tell the user to 'dmd -run dfix.d'. Now you have a very clear intermediate step between compilation and user-activated step.

Not a bad idea.  Maybe this will be less "creepy" to others :)

+1 (what do others think?)