On Wednesday, 28 January 2015 at 15:18:44 UTC, Kagamin wrote:
>> Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords.
>
> Same for any symbol. Do you have a solution?

Long time ago I have proposed to actually define built-it attributes as UDA's in public druntime module. That way any possible conflict can be resolved relatively easy with dfix using module system disambugation (or just hard-code druntime symbols to be legal to shadow by user ones, though that sounds too much of a magic and surprise)

>> I don't see any _vision_ behind the change, just moving bits around.
>>
>> It is not well-thought.
>
> @pure, @nothrow and @return are relatively obscure attributes, so if they change, it should cause minor commotion. If you want to overhaul everything, you can propose a DIP.

The one who wants to make a change should propose a DIP. I am personally OK with status quo for the time being - there are more important issues.

On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis wrote:
> > consistent. They're
> > always going to be inconsistent in one way or another, even if
> > it's simply
> > because they don't match what anyone coming from other
> > languages expects
>
> The logical conclusion from that statement would be that D semantics are fundamentally broken...

Not really. For instance, we could make the attributes "completely consistent" by adding @ to all of them - @pure, @public, @const, etc. But that would cause inconsistencies with other languages that have many of the same attributes, and it would likely cause far more complaining than the current situation has.

We could also remove @ from all of the attributes, and then that would be "completely consistent," because then only UDAs will have @ on them. But the next time that we need to add a new attribute (which will hopefully be rare, but it happens sometimes - e.g. with @nogc recently), then we'd have to add a new keyword to avoid making things inconsistent, which would likely break existing code. So, more likely, we'd just tack @ onto it (which can still break code, but only UDA-specific code, so the breakage would be far more minimal), and we'd be right back where we are now.

And any situation where some of the attributes have @ on them and some don't will almost certainly result in arguments about whether the rationale makes sense and whether one or more of the attributes really belongs in the camp that it's in, so how consistent it is would depend on the eye of the beholder.

I don't see any of that as being something fundamentally broken with the semantics of D. It's just life with designing a programming language - especially one which isn't 100% set in stone. There are _always_ inconsistencies and annoying points in the language. And much of the time, those inconsistencies and annoying points are forced by other aspects of the language that actually make things nice and clean. There are always tradeoffs, and often, there is no clear, right answer to how it should be. And I think that this is one of those cases.

- Jonathan M Davis

On 1/28/15 7:25 AM, Dicebot wrote:
> The one who wants to make a change should propose a DIP. I am personally
> OK with status quo for the time being - there are more important issues.

BTW what's the deal with std.meta? -- Andrei

On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote:
> On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote:
>> On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis
>> wrote:
>> > consistent. They're
>> > always going to be inconsistent in one way or another, even if
>> > it's simply
>> > because they don't match what anyone coming from other
>> > languages expects
>>
>> The logical conclusion from that statement would be that D
>> semantics are fundamentally broken...
>
> Not really. For instance, we could make the attributes "completely
> consistent" by adding @ to all of them - @pure, @public, @const, etc. But
> that would cause inconsistencies with other languages that have many of the
> same attributes, and it would likely cause far more complaining than the
> current situation has.
>
> We could also remove @ from all of the attributes, and then that would be
> "completely consistent," because then only UDAs will have @ on them. But the
> next time that we need to add a new attribute (which will hopefully be rare,
> but it happens sometimes - e.g. with @nogc recently), then we'd have to add
> a new keyword to avoid making things inconsistent, which would likely break
> existing code. So, more likely, we'd just tack @ onto it (which can still
> break code, but only UDA-specific code, so the breakage would be far more
> minimal), and we'd be right back where we are now.

Actually we could support removing the '@' symbol from all attributes without making them keywords :)  It would be quite simple to do (probably a day of work in DMD, in parser.c and a couple other places that use the code tree).  At least for the attributes on the right side of the function signature.  For the attributes on the left-hand side, it may make the syntax ambiguous...not sure.  The idea is we allow non-keyword identifiers to be used as function attributes (on the right hand side).

On Wednesday, 28 January 2015 at 15:40:31 UTC, Andrei Alexandrescu wrote:
> On 1/28/15 7:25 AM, Dicebot wrote:
>> The one who wants to make a change should propose a DIP. I am personally
>> OK with status quo for the time being - there are more important issues.
>
> BTW what's the deal with std.meta? -- Andrei

I have replied today in relevant PR with few proposals. That one is important to me so I'll keep babysitting it :)

On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
> On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:
>> Assuming I understand the problem, couldn't we modify the language grammar to support more attributes without making them keywords?  Then we can omit the '@' on future code (and fix the old code if we want) and we don't have to litter the language with new keywords.
>>
>> I understand that doing this may be fairly complicated.  This may create some ambiguities in the grammar that would need to be handled carefully, but if it can work I think this would be a good option.
>
> I think the short answer is that it's WAY too complicated for the benefit. Also, why burden the syntax highlighter, let alone the human reader, with ambiguities like this?

I don't agree that it's complicated, it's just not the most beautiful thing. But it is already used in several places.

As for the syntax highlighters, any identifiers between `)` and `{`, or `)` and `;` can be treated as function attributes, except those that are already known to be keywords. No problem there. And for human readers it would be even easier, because now all function attributes have to be placed on the right side of the declaration.

On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote:
> Ya same thing applies to "body".  I'm surprised no one has given a reason why it wasn't done this way.

I made a PR, but it was not too well-received:
https://github.com/D-Programming-Language/dmd/pull/3227

On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote:
> inconsistencies and annoying points in the language. And much of the time,
> those inconsistencies and annoying points are forced by other aspects of the
> language that actually make things nice and clean. There are always
> tradeoffs, and often, there is no clear, right answer to how it should be.

I think I misinterpreted what you meant to say, but if the semantics are good and sound then you should be able to device a consistent syntax for the language that is in line with current terminology in comp sci (even if that means pointing to Wikipedia for a definition of the term).

That would of course mean a lot of changes to D terminology:

"const" => "readonly"
"enum" => "const"
"range"=>"iterator"
"pure"=>"no global effect"
"ubyte" => "byte"
"lazy" => "by name"
etc...

On 1/28/15 7:50 AM, Dicebot wrote:
> On Wednesday, 28 January 2015 at 15:40:31 UTC, Andrei Alexandrescu wrote:
>> On 1/28/15 7:25 AM, Dicebot wrote:
>>> The one who wants to make a change should propose a DIP. I am personally
>>> OK with status quo for the time being - there are more important issues.
>>
>> BTW what's the deal with std.meta? -- Andrei
>
> I have replied today in relevant PR with few proposals. That one is
> important to me so I'll keep babysitting it :)

Link: https://github.com/D-Programming-Language/phobos/pull/2687

Andrei

On Wednesday, January 28, 2015 16:10:28 via Digitalmars-d wrote:
> On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote:
> > inconsistencies and annoying points in the language. And much
> > of the time,
> > those inconsistencies and annoying points are forced by other
> > aspects of the
> > language that actually make things nice and clean. There are
> > always
> > tradeoffs, and often, there is no clear, right answer to how it
> > should be.
>
> I think I misinterpreted what you meant to say, but if the semantics are good and sound then you should be able to device a consistent syntax for the language that is in line with current terminology in comp sci (even if that means pointing to Wikipedia for a definition of the term).
>
> That would of course mean a lot of changes to D terminology:
>
> "const" => "readonly"
> "enum" => "const"
> "range"=>"iterator"
> "pure"=>"no global effect"
> "ubyte" => "byte"
> "lazy" => "by name"
> etc...

I don't see what any of that has to do with which attributes have @ on them or not.

The problem is that any situation where some of the attributes have @ and some don't is going to cause some confusion, whereas putting @ on all of them would create inconsistencies with the expectations of folks coming from other languages and make porting code to D more annoying, and putting @ on none of them means that we're consistent but would mean that every time that we had to introduce a new built-in attribute (which we don't want to do much more of, but it still happens occasionally), we would either break existing code (because it would mean introducing a new keyword), or we'd have to put @ on it (making things inconsistent again, but only risking breaking UDA code, which is less prevalent).

If we could start from scratch and guarantee that no new attributes would ever be introduced, then we could just put @ on none of them and thus be fully consistent. But we can't start from scratch, and we can't guarantee that there will be no new attributes. And even then, instead of getting complaints about being inconsistent with @, then we'd get even more complaints about the number of keywords that we have.

There is no way to win here. No matter what we do, there will be screaming from someone. And whether the language would be objectively improved would be debatable.

There may be set of changes that would ultimately be better enough that they'd be worth making - where the pros are generally considered to outweigh the cons - but we'll be stuck with the cons regardless, and I seriously question that any change to attribute names is enough of an improvement to merit the code breakage that it would cause, even if it were objectively better.

- Jonathan M Davis