On Wednesday, 28 January 2015 at 16:39:51 UTC, Jonathan M Davis wrote:
> I don't see what any of that has to do with which attributes have @ on them or not.

As I said, I misinterpreted what you wrote. You came through as being overly defensive when it comes to accepting a syntax with bad usability.

It does affect both usability and marketing what the syntax looks like and whether the terminology is consistent with definitions. It sends signals about the design and the implementation that will be picked up by people who evaluate the language. For instance, the syntax of Cray's Chapel sends strong signals of the designers know what they are doing, so I am more inclined to give it a spin...

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

Of course you can, but you need to get the semantics right first.

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

That's one viewpoint. An alternative viewpoint is that when/if D has reached a stable state, then it is a relatively small task for someone (1-2 people) to fork the language, design a new grammar and implement a parser for it that maps to the compiler internals. It is not a big project to write a new parser if the rest is stable.

Syntactical code breakage is not a real problem, since:

1. the D corpus is small
2. transpilers can do source-to-source compilation
3. a compiler can include multiple parsers for the same language semantics

Except... string mixins.

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

I would love this, and I would be fine with the breakage costs, speaking for myself.

About the problem of add more attributes in the future: well, maybe that solution will put a rubber floor on the number of attributes that can be added, as they are already a big number really....

It would be interesting an implementation of both the solutions, and recompile a bunch of big projects out from the registry with dub, just to finally move the discussion on numbers instead of "likely would break a lot / lot more / not so much breakage / etc" ...

I know the reply: help us trying out instead of writing!  ;-P ;-P

---
Paolo

On Tuesday, 27 January 2015 at 01:14:01 UTC, Zach the Mystic wrote:
> On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler wrote:
>> On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic
>>> 3. Singularity of usage also matters. There should only be one
>>> way to mark a given attribute, either with or without `@`.
>>
>> I agree that the proposal doesn't solve the consistency issue, but the proposal doesn't make things more inconsistent then they already are. It adds another way to write these attributes, but it adds a way that makes more sense in my opinion.  This is a step in the right direction in solving the problem.  The next step would be to solve the consistency issue, but again, that's another debate. To conclude, which code would you rather write?
>
> The consistency issue is precisely that there should not be more than one way to write an attribute. Note that that's precisely where most of the opposition to this thread's original proposal came from. Uniformity means never having to explain to anybody why there is more than one way to do something. Both this thread's proposal and your proposal *introduce* inconsistency in this way.
>

The old syntax can be deprecated and removed after an appropriate period.

> 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.
>
I have proposed a way that I think is a win win.  Add support for non-keyword function attributes on the right hand side of a function signature.  This will not break any code since it does not require removing support for using '@' for function attributes.  Then later we can deprecate support for the '@' character if we feel like it's worth breaking code.

void foo() safe; // now valid, and safe is not a keyword
safe void foo(); // still not valid, might make the grammar
                 // ambiguous, if it does not then it could
                 // be supported later
void foo() @safe; // Still ok (can be deprecated)

It's simple to remember that if you put the function attribute on the right hand side then no '@' is required.  Plus, this will encourage developers to put their attributes on the right hand side in the future so they can remove the '@' character.

PLUS, this would be very simple to implement!

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

My proposal will not break any code.

On Monday, 26 January 2015 at 19:59:58 UTC, H. S. Teoh wrote:
> On Mon, Jan 26, 2015 at 11:50:19AM -0800, Walter Bright via Digitalmars-d wrote:
>> On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
>> >Personally, I'd much prefer that we not make this change.
>> 
>> It's good to have this discussion.
>> 
>> Previously, it's all been advocacy and "break my code" by forcing a
>> change from pure => @pure.
>> 
>> Just a few days ago on slashdot, an anonymous D user wrote:
>> 
>>   "A horrible mix of keywords and annotation syntax for
>>   function/method attributes ('const', 'pure', and 'nothrow' are all
>>   keywords, but '@property', and '@nogc' are annotations)"
>> 
>> for why he won't use D anymore.
>> 
>> Frankly, I think that is a great bikeshedding non-issue that distracts
>> us from what is important. I hope that by doing this PR, we can
>> actually decide that it isn't worth it, i.e. I'd be happy to get
>> consensus and revert it.
>
> While I generally agree with the sentiment that this great debate over
> syntax is distracting from more important issues, one particularly
> attractive point about forcing @ on annotations is that const (as a type
> qualified) and @const (as a function annotation) become syntactically
> distinct:
>
> 	const int myFunc() @const {}
>
> vs. the current confusing syntax:
>
> 	const int myFunc() const {}
>
> Does this alone make it worth it? I'm skeptical. But I thought it should
> be pointed out regardless.

I wouldn't count `const` among functions annotations. It applies to `this`, not to the function.

On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:
> I have proposed a way that I think is a win win.  Add support for non-keyword function attributes on the right hand side of a function signature.  This will not break any code since it does not require removing support for using '@' for function attributes.  Then later we can deprecate support for the '@' character if we feel like it's worth breaking code.

I agree. This would also be a nice way to introduce dfix. And while we're at it, we can also move `const` etc. applying to the implicit `this` to the right side, too, so that this falltrap goes away, too.

On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:

> PLUS, this would be very simple to implement!

Then I recommend you submit a pull request.

Mike

On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
> On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:
>
>> PLUS, this would be very simple to implement!
>
> Then I recommend you submit a pull request.
>
> Mike

I would but Walter said no.  I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it.  I'm not sure what to do here.  If I get the go ahead from Walter or anyone who would be able to merge the PR then I would happily do the work :)  For some reason no one with power is addressing my proposal.

Andrei? Jonathan? Dicebot? Walter?

Walter I know you've been responding to most of my posts, but again, I think you are misinterpreting my proposal.  For some reason it seems like you think I'm trying to make the lexer be context-sensitive.  My proposal would not touch the lexer.

On 1/28/15 10:19 AM, Jonathan Marler wrote:
> On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
>> On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:
>>
>>> PLUS, this would be very simple to implement!
>>
>> Then I recommend you submit a pull request.
>>
>> Mike
>
> I would but Walter said no.  I'm certain he misunderstood my proposal
> and I tried to explain it to him but I couldn't get him to address it.

Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST?

> Here's what would change
> -----------------------------------------------------------------
> void myfunc() nogc; // VALID (Only if this proposal is accepted)
> void myfunc() safe; // VALID (Only if this proposal is accepted)
>
>
> Here's what WOULD NOT change
> -----------------------------------------------------------------
> nogc myfunc(); // STILL INVALID: invalid unless it can be verified
>                //          that this wouldn't result in ambiguity
>                //          in the grammar
> void myfunc() @nogc; // STILL VALID (no change)
> @nogc myfunc(); // STILL VALID (no change)


Andrei

On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote:
> On 1/28/15 10:19 AM, Jonathan Marler wrote:
>> On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote:
>>> On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote:
>>>
>>>> PLUS, this would be very simple to implement!
>>>
>>> Then I recommend you submit a pull request.
>>>
>>> Mike
>>
>> I would but Walter said no.  I'm certain he misunderstood my proposal
>> and I tried to explain it to him but I couldn't get him to address it.
>
> Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST?
>
>> Here's what would change
>> -----------------------------------------------------------------
>> void myfunc() nogc; // VALID (Only if this proposal is accepted)
>> void myfunc() safe; // VALID (Only if this proposal is accepted)
>>
>>
>> Here's what WOULD NOT change
>> -----------------------------------------------------------------
>> nogc myfunc(); // STILL INVALID: invalid unless it can be verified
>>               //          that this wouldn't result in ambiguity
>>               //          in the grammar
>> void myfunc() @nogc; // STILL VALID (no change)
>> @nogc myfunc(); // STILL VALID (no change)
>
>
> Andrei

You can follow this thread: http://forum.dlang.org/post/fxbqqecgqdhrepxsjnep@forum.dlang.org

I explained my proposal 3 or 4 times but each time Walter seemed to be misunderstanding my proposal saying it was going to create "context-sensitive" tokens and so he would immediately dismiss it.  I tried to understand what he meant by "context-sensitive" tokens because my proposal didn't have anything to do with them (at least my definition of them), but even after he defined them my proposal clearly does not create them.

Walter "[A context-sensitive token is] A keyword in one context and an identifier in another"

Anyway, I'll restate my proposal again:

1. Modify the SYNTAX of function to allow it to be decorated with IDENTIFIER tokens on the right hand side

void foo() x; // valid SYNTAX (note: has not semantic meaning)
void foo() safe; // valid SYNTAX and valid SEMANTICS

2. Modify the code that interprets the syntax tree to recognize these identifiers as function attributes.

A simple solution that would allow us to standardize where we put the function attributes and allow us to remove the '@' character from all non-keyword function attributes.  Seems like a no-brainer to me.