On Wednesday, 28 January 2015 at 19:46:33 UTC, Andrei Alexandrescu wrote:
> I'd say we just drop it. It's a waste of time to talk about it. There's no proof on why the idea isn't accepted, and there's no need for one.
>
> I just wrote out of empathy. As a newcomer to language communities (including this one) I've had literally dozens of ideas on how they can be improved. All looked great to myself at the time, and of them some felt actually unassailably good. So good, in fact, that I'd attach a sense of importance to them and was convinced that explaining and advertising them well was essential, and that opponents didn't really understand their advantages. For the most part they were in reality weak ideas of a n00b, ideas of greatly overstated merit, and acknowledging that has made me better.
>
>
> Andrei

Maybe this is a weak proposal but I don't know how to realize that unless I ask the people who oppose it to explain themselves.  How else will I learn?

My proposal would be a nice feature but like I've said, it's not a huge deal. There's so many more important things to worry about.  However, I don't think it's unreasonable to ask someone to explain why they do or don't like something.  I believe I'm being pragmatic here.  What's frustrating to me isn't that my proposal wasn't accepted, its that it was so hard to communicate over such a simple issue.  It took so much time and everything had to be said over and over again.

But at least I have a reason why it was rejected.  Now I can tell people, the leadership in D does not like to have a word be a function attribute in one place and normal identifier in another place.  I would like to understand why the leadership does not want this but since there are more important things, and time is a finite resource, consider this issue "let go".

Thanks Andrei, I appreciate your input on this.  Now if you can get that list of high priority issues out so I can know what I should be working on that would be great!

On Wednesday, 28 January 2015 at 19:07:59 UTC, Jonathan Marler wrote:
> On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic wrote:
>> I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. Walter said that `exit`, `C++`, i.e. `scope(exit)`, `extern (C++)` etc. were never keywords, but I disagree. They are indeed context sensitive keywords. They have wisely been kept to a minimum. They are just confusing to reason about, except in the most strictly confined places, where they are now. I think that's why they're out of the question. They have wisely been kept to a minimum.
>
> This is actually a valid argument against my proposal.  Thank you! lol.  I don't agree with it but at least it's valid :)  Your reasoning depends on how you define a keyword.  You seem to be defining a keyword in terms of an identifier that is recognized by the compiler to have a special meaning.  I define a keyword as a word that the lexer recognizes as a keyword token.
>
> I see what you mean by saying that the word is a function attribute in one place and an identifier in another.  But what's wrong with that?  if I define a struct named mystruct...I could declare one like this:
>
> mystruct mystruct;

It's utterly confusing is the problem. I would consider it a great disservice to all D programmers to allow this. Just because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words. There is however, a shortage of what a programmer can keep organized in his head. That's the shortage you should prioritize, sir. I'm not sure how to emphasize this anymore. We may just have to agree to disagree.

On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic wrote:
> because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words.

@can @you @spot @the @contradiction @?

Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v 19:33 +0000:
> On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:
> >> I would think the reason would be it could make the grammar ambiguous.  That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity.  Other then that, I don't see any reason why it's a bad thing.  It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.
> >
> > Thats not possible:
> >
> > @safe {
> >     void some func() // now valid
> > }
> >
> > safe:
> >     void some func() // now valid
> >
> >
> >
> > safe {
> >     void some func() // could not be valid
> > }
> >
> > safe:
> >     void some func() // could not be valid
> >
> >
> > So you need more places where keyword needs to be contextual keyword
> >
> > And this is a path I am not sure we want to go.
> 
> None of those cases would valid.  Non-Keyword attributes without a '@' must be on the right hand side of the function parameters.
> 
> void some func(); // some is not a keyword, so it is invalid

Typo I mean some_func

On Wednesday, 28 January 2015 at 21:37:02 UTC, Daniel Kozak wrote:
> Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v 19:33 +0000:
>> On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:
>> >> I would think the reason would be it could make the grammar ambiguous.  That's why I proposed it only be valid on the right hand side of the function to guarantee it doesn't introduce any ambiguity.  Other then that, I don't see any reason why it's a bad thing.  It doesn't make the syntax more complicated, it doesn't maker it harder to parse, I just don't see why its bad.
>> >
>> > Thats not possible:
>> >
>> > @safe {
>> >     void some func() // now valid
>> > }
>> >
>> > safe:
>> >     void some func() // now valid
>> >
>> >
>> >
>> > safe {
>> >     void some func() // could not be valid
>> > }
>> >
>> > safe:
>> >     void some func() // could not be valid
>> >
>> >
>> > So you need more places where keyword needs to be contextual keyword
>> >
>> > And this is a path I am not sure we want to go.
>> 
>> None of those cases would valid.  Non-Keyword attributes without a '@' must be on the right hand side of the function parameters.
>> 
>> void some func(); // some is not a keyword, so it is invalid
>
> Typo I mean some_func

Oh ok.  Then I'm not sure what your trying to say with your examples.  The proposal is that you could only omit the '@' symbol if the word appeared after the function parameters.

safe void foo(); // STILL NOT VALID
void foo() safe; // NOW VALID

If it comes before, then you still need the '@'.

@safe void foo(); // STILL VALID (no change), however,
                  // this usage would be discouraged

Your examples do bring up a usage I hadn't thought of though.  It would be a bit odd for newcomers to use "safe" without an '@' in one case and then have to include the '@' another case (the example you provided).  This makes it less appealing.  Either way, I don't think it matters since the proposal isn't acceptable for a different reason, the leadership doesn't like the same words to be used as function attributes sometimes and identifiers other times.

On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler wrote:
> Thanks Andrei, I appreciate your input on this.  Now if you can get that list of high priority issues out so I can know what I should be working on that would be great!

+1.000.000.000

(Finally an empathic confession for betterment!)

On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic wrote:
> It's utterly confusing is the problem. I would consider it a great disservice to all D programmers to allow this. Just because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words. There is however, a shortage of what a programmer can keep organized in his head. That's the shortage you should prioritize, sir. I'm not sure how to emphasize this anymore. We may just have to agree to disagree.

I don't think this is confusing:

void foo() safe {
    bool safe = false;
}

Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit.  Let's consider this resolved and move on to better more interesting things:)  I appreciate you taking the time to voice your opinion and helping me understand the arguments against this idea.

On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler wrote:
> Maybe this is a weak proposal but I don't know how to realize that unless I ask the people who oppose it to explain themselves.
>  How else will I learn?

I also think arguing is a very good way to learn too - but please don't forget that Walter time is extremely precious and if understanding has not been achieved quickly enough it may be better to drop the discussion for a while. Later more data may appear, context may change, Walter opinion may change (that happens!) and another small iteration will yield much more productive results.

On 1/28/2015 1:46 PM, Jonathan Marler wrote:
> Your examples do bring up a usage I hadn't thought of though.  It would be a bit
> odd for newcomers to use "safe" without an '@' in one case and then have to
> include the '@' another case (the example you provided).  This makes it less
> appealing.  Either way, I don't think it matters since the proposal isn't
> acceptable for a different reason, the leadership doesn't like the same words to
> be used as function attributes sometimes and identifiers other times.


Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program.

For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially.

So consider:

    void func()
    safe T = 7;

With your proposal, an error isn't discovered until the '=' is found. But what kind of error is it? Did the user mean:

    void func() safe;
    void func() safe T;
    void func(); safe T = 7;

Even for humans it can be hard to discern what the user meant it to be, especially if he also is not using whitespace formatting as further redundancy.

Keywords and punctuation form "anchors" that both humans, syntax highlighters, and parsers use to add redundancy and "synchronization points" (which enable error recovery, such as "give up on the current AST and scan forward to find the next anchor and start afresh").

On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote:
> Using "safe" as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit.

Now you disappoint me. Your rebellious mindset has been poisoned by the Evil Spirit of Gn@sh. Thou shalt not give up yer own freedom to choose yer own identifiers for heavens sake.

Maintain yer own parse.c like everybody else!!!

That's what ketmar and I do. It is known as Free Software Freedom.