www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - accept pure nothrow return attributes

reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
If someone is not following the merges, well...  [1] !!

---
Paolo

[1] 
http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mail
Jan 26 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi 
wrote:
 If someone is not following the merges, well...  [1] !!

 ---
 Paolo

 [1] 
 http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mail
I'm running out of ideas for DConf topics.
Jan 26 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/15 1:50 AM, Brian Schott wrote:
 On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:
 If someone is not following the merges, well...  [1] !!

 ---
 Paolo

 [1]
 http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mail
I'm running out of ideas for DConf topics.
Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei
Jan 26 2015
next sibling parent "Meta" <jared771 gmail.com> writes:
On Monday, 26 January 2015 at 09:54:31 UTC, Andrei Alexandrescu 
wrote:
 On 1/26/15 1:50 AM, Brian Schott wrote:
 On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi 
 wrote:
 If someone is not following the merges, well...  [1] !!

 ---
 Paolo

 [1]
 http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mail
I'm running out of ideas for DConf topics.
Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei
The extra glyphs add a bit of visual noise, but I think that's balanced out by the better consistency of the language and the growing sphere of functions which can have their attributes inferred.
Jan 26 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, January 26, 2015 01:54:36 Andrei Alexandrescu via Digitalmars-d
wrote:
 On 1/26/15 1:50 AM, Brian Schott wrote:
 On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote:
 If someone is not following the merges, well...  [1] !!

 ---
 Paolo

 [1]
 http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mail
I'm running out of ideas for DConf topics.
Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei
In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without , then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without , then we'll be forced to change pretty much every D program in existence. But It's not like this really improves consistency all that much anyway, because public, protected, package, private, final, override, static, const, immutable, inout, and deprecated all don't have . So, most function attributes _don't_ have on them, and we just added to some of them, making things even _less_ consistent. In fact, priore to this, safe, trusted, system, and property were the _only_ function attributes with on them. So, if we really wanted to improve consistency IMHO, we'd get rid of from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. Ultimately, I really don't see this as an improvement, because it really doesn't fix the consistency problem with attributes, and we're either going to have to change existing code or end up with both pure and pure, and nothrow and nothrow in the language, which is just ugly. But aside from having duplicate attributes for the same thing, I don't know that it really makes things any worse - though at least before this, we could just say that property, safe, trusted, and system were oddballs that were added late in the game and that they had , because we didn't want to add new keywords. With this change, I expect that it will be even less clear which attributes have on them and which don't. Personally, I'd much prefer that we not make this change. It's just shuffling things around in an attempt to make them more consistent while actually making them _less_ consistent. - Jonathan M Davis
Jan 26 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan M Davis:

 Personally, I'd much prefer that we not make this change. It's 
 just shuffling things around in an attempt to make them more 
 consistent while actually making them _less_ consistent.
So far I agree with Jonathan. Bye, bearophile
Jan 26 2015
parent reply Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-01-26 21:03 GMT+09:00 bearophile via Digitalmars-d <
digitalmars-d puremagic.com>:

 Jonathan M Davis:

  Personally, I'd much prefer that we not make this change. It's just
 shuffling things around in an attempt to make them more consistent while
 actually making them _less_ consistent.
So far I agree with Jonathan. Bye, bearophile
Me too. At best it is just a cosmetic change, and will introduce huge code style confusion. We should revert it quickly. Kenji Hara
Jan 26 2015
parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Monday, 26 January 2015 at 13:57:13 UTC, Kenji Hara wrote:
 2015-01-26 21:03 GMT+09:00 bearophile via Digitalmars-d <
 digitalmars-d puremagic.com>:

 Jonathan M Davis:

  Personally, I'd much prefer that we not make this change. 
 It's just
 shuffling things around in an attempt to make them more 
 consistent while
 actually making them _less_ consistent.
So far I agree with Jonathan. Bye, bearophile
Me too. At best it is just a cosmetic change, and will introduce huge code style confusion. We should revert it quickly. Kenji Hara
Yes we should, it does not fix anything
Jan 26 2015
prev sibling next sibling parent "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis 
wrote:
 But It's not like this really improves consistency all that 
 much anyway,
 because public, protected, package, private, final, override, 
 static, const,
 immutable, inout, and deprecated all don't have  . So, most 
 function
 attributes _don't_ have   on them, and we just added   to some 
 of them,
 making things even _less_ consistent. In fact, priore to this, 
  safe,
  trusted,  system, and  property were the _only_ function 
 attributes with  
 on them. So, if we really wanted to improve consistency IMHO, 
 we'd get rid
 of   from everything that's built-in and leave it for 
 user-defined
 attributes, but that would break existing code too.
 - Jonathan M Davis
At this point, it might be nicer to have only attributes that exists as C++ keywords not having the identifier before them. That is: public, protected, private, override, deprecated, static and const. But this probably doesn't make much sense now, does it?
Jan 26 2015
prev sibling next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
+1

On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis 
wrote:
 On Monday, January 26, 2015 01:54:36 Andrei Alexandrescu via 
 Digitalmars-d wrote:
 On 1/26/15 1:50 AM, Brian Schott wrote:
 On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi 
 wrote:
 If someone is not following the merges, well...  [1] !!

 ---
 Paolo

 [1]
 http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mail
I'm running out of ideas for DConf topics.
Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei
In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without , then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without , then we'll be forced to change pretty much every D program in existence. But It's not like this really improves consistency all that much anyway, because public, protected, package, private, final, override, static, const, immutable, inout, and deprecated all don't have . So, most function attributes _don't_ have on them, and we just added to some of them, making things even _less_ consistent. In fact, priore to this, safe, trusted, system, and property were the _only_ function attributes with on them. So, if we really wanted to improve consistency IMHO, we'd get rid of from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. Ultimately, I really don't see this as an improvement, because it really doesn't fix the consistency problem with attributes, and we're either going to have to change existing code or end up with both pure and pure, and nothrow and nothrow in the language, which is just ugly. But aside from having duplicate attributes for the same thing, I don't know that it really makes things any worse - though at least before this, we could just say that property, safe, trusted, and system were oddballs that were added late in the game and that they had , because we didn't want to add new keywords. With this change, I expect that it will be even less clear which attributes have on them and which don't. Personally, I'd much prefer that we not make this change. It's just shuffling things around in an attempt to make them more consistent while actually making them _less_ consistent. - Jonathan M Davis
Jan 26 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis 
wrote:
 immutable, inout, and deprecated all don't have  . So, most 
 function
 attributes _don't_ have   on them, and we just added   to some 
 of them,
 making things even _less_ consistent. In fact, priore to this, 
  safe,
  trusted,  system, and  property were the _only_ function 
 attributes with  
 on them. So, if we really wanted to improve consistency IMHO, 
 we'd get rid
 of   from everything that's built-in and leave it for 
 user-defined
 attributes, but that would break existing code too.
I agree that you need to let " " act as some kind of mnemonic and therefore assign meaning to it. One meaning would be to only use " " with attributes that do not affect computation, typing, overloading etc and use it only for safety-checks and optimization hints (like inlining). Besides it would be easy to change the parser so that terms can be reused as symbols if the grammar stays sound. I think that is true for most function attributes anyway.
Jan 26 2015
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:
 One meaning would be to only use " " with attributes that do not
 affect computation, typing, overloading etc and use it only for
 safety-checks and optimization hints (like inlining).
All of the existing affect the type of the function. It's attributes like public or static which don't, and those still affect aspects of compilation and can easily cause compilation errors. There are not currently any attributes which are simply hints to the compiler, and the ones which affect the safety checks are _definitely_ part of the type of the function. So, I don't think that that particular distinction would work, even if we could freely rearrange which attributes had and which didn't. - Jonathan M Davis
Jan 26 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 26 January 2015 at 15:07:24 UTC, Jonathan M Davis 
wrote:
 On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:
 function. So, I
 don't think that that particular distinction would work, even 
 if we could
 freely rearrange which attributes had   and which didn't.
I personally agree that it would be better to remove " " like you suggested and leave it for UDAs. Interpreting D code is hard for tools without a library anyway, so I think the current approach is unwarranted, and would rather see a more complicated grammar and parser in favour of usability. D could provide an official parser/semantic analysis library available for tools (like clang). The visual noise in D2 is too high IMO, and the reuse of keywords/symbols for unrelated functionality makes usability/legibility/reading comprehension worse. I think this alone is enough to prevent mainstream adoption. Other languages compensate by having constructs that allow you do use "keywords" for fieldnames in records. It is a better strategic move to favour good syntactical usability/legibility over parsing complexity. Clean context independent mapping between syntax and semantics is important. Besides, D really needs to allow the use of common nouns like "body" in structs (e.g. to implement the HTML DOM)... so a more wholesome approach to rethinking the D syntax would be welcome. The D syntax needs rethinking as a whole, not in bits and pieces. If you are gonna break, make it clean, and make the language easy to learn.
Jan 26 2015
prev sibling parent Kenji Hara via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-01-27 0:07 GMT+09:00 Jonathan M Davis via Digitalmars-d <
digitalmars-d puremagic.com>:

 On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:
 One meaning would be to only use " " with attributes that do not
 affect computation, typing, overloading etc and use it only for
 safety-checks and optimization hints (like inlining).
All of the existing affect the type of the function. It's attributes like public or static which don't, and those still affect aspects of compilation and can easily cause compilation errors. There are not currently any attributes which are simply hints to the compiler, and the ones which affect the safety checks are _definitely_ part of the type of the function. So, I don't think that that particular distinction would work, even if we could freely rearrange which attributes had and which didn't.
Additional note: UDA can be attached to symbols only. void foo() uda {} // __traits(getAttributes, foo) == (uda) // pragma(msg, typeof(foo)); prints void(), no uda void function() uda fp; // Error: user defined attributes cannot appear as postfixes Kenji Hara
Jan 26 2015
prev sibling next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
I agree with Jonathan's points, this solution doesn't seem like 
an improvement.   If I understand the problem, we don't want to 
make every attribute use the ' ' symbol because it looks bad and 
would cause a lot of code changes for sake of consistency.  
However, on the other hand, we don't want to support the new 
properties because we have to add them as keywords which would 
break code using those words and would make the language more 
restrictive (nothing can be named nogc/safe/...).

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.
Jan 26 2015
next sibling parent reply "Foo" <Foo test.de> writes:
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:
 I agree with Jonathan's points, this solution doesn't seem like 
 an improvement.   If I understand the problem, we don't want to 
 make every attribute use the ' ' symbol because it looks bad 
 and would cause a lot of code changes for sake of consistency.  
 However, on the other hand, we don't want to support the new 
 properties because we have to add them as keywords which would 
 break code using those words and would make the language more 
 restrictive (nothing can be named nogc/safe/...).

 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.
You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.
Jan 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 8:13 AM, Foo wrote:
 You could do the same as C++ with override and final: they are only valid
 attributes if they appear _after_ the function/method. Elsewhere they are still
 valid as identifiers for e.g. variables.
Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation).
Jan 26 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright wrote:
 On 1/26/2015 8:13 AM, Foo wrote:
 You could do the same as C++ with override and final: they are 
 only valid
 attributes if they appear _after_ the function/method. 
 Elsewhere they are still
 valid as identifiers for e.g. variables.
Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation).
Some words are in high demand, however, like body and match.
Jan 26 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 26 Jan 2015 19:46:21 +0000, Meta wrote:

 On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright wrote:
 On 1/26/2015 8:13 AM, Foo wrote:
 You could do the same as C++ with override and final: they are only
 valid attributes if they appear _after_ the function/method. Elsewhere
 they are still valid as identifiers for e.g. variables.
Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation).
=20 Some words are in high demand, however, like body and match.
body will not be "dekeyworded". Walter Bright 2014-02-12 14:44:20 UTC=20 In hindsight, the choice of 'body' for the keyword is unfortunate. But=20 fixing it would cause even worse problems, so I think we're stuck with it. nobody told us what "worse problems" are. using "body" is not confusing,=20 lowering it into identifier will not break any code, but... "worse=20 problems" awaits. i'm using patch that allows "body" as identifier for almost a year, i'm=20 constantly building alot of projects from dub repo, and i haven't=20 encountered any problems with it. but i believe that i'm simply doing=20 something wrong and dragons are around the corner.=
Jan 26 2015
prev sibling next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright wrote:
 On 1/26/2015 8:13 AM, Foo wrote:
 You could do the same as C++ with override and final: they are 
 only valid
 attributes if they appear _after_ the function/method. 
 Elsewhere they are still
 valid as identifiers for e.g. variables.
Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation).
I'm not sure what you mean by "context-sensitive tokens". It sounds like you might be saying that this requires the tokenizer to be context sensitive, but this isn't the case. Instead, allowing a function to be decorated with any number of "id" or "keyword" tokens would allow the language to add new attributes (without a ' ' character) by restricting the usage of attributes in the semantics instead of the syntax. void myfunc() foo bar safe nogc nothrow { } 'foo' and 'bar' don't break the syntax but are caught by the semantic analysis. Furthermore, I'm sure this type of thing is already done all over the place in the grammar. The following example comes to mind: struct St { } void main() { St St; } The "St" token is a decl type the first time and a variable name the second. I'm sure they are implemented as the same token but the grammar results in a different semantic meaning for both tokens.
Jan 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 12:34 PM, Jonathan Marler wrote:
 I'm not sure what you mean by "context-sensitive tokens".
A keyword in one context and an identifier in another.
Jan 26 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 26 January 2015 at 20:38:43 UTC, Walter Bright wrote:
 On 1/26/2015 12:34 PM, Jonathan Marler wrote:
 I'm not sure what you mean by "context-sensitive tokens".
A keyword in one context and an identifier in another.
Then I'm a little confused. What does this have to do with adding new attributes to a function? Just because a word is used as a function attribute doesn't mean it has to be a keyword. If the grammar supported decorating a function with a list of id tokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. Just because they are function attributes does not mean they were tokenized as "keywords".
Jan 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 12:45 PM, Jonathan Marler wrote:
 Just because they are function attributes does not mean
 they were tokenized as "keywords".
The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.
Jan 26 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:
 On 1/26/2015 12:45 PM, Jonathan Marler wrote:
 Just because they are function attributes does not mean
 they were tokenized as "keywords".
The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.
Not a problem, the parser can turn the token it back into a string. All you need is a LUT. ( Besides, parser.c is screaming for a rewrite anyway... )
Jan 26 2015
prev sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:
 On 1/26/2015 12:45 PM, Jonathan Marler wrote:
 Just because they are function attributes does not mean
 they were tokenized as "keywords".
The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.
I feel like I keep repeating myself so I'm just going to copy/paste.
 If the grammar supported decorating a function with a list of id
tokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.
Jan 26 2015
next sibling parent reply "Foo" <Foo test.de> writes:
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:
 On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright wrote:
 On 1/26/2015 12:45 PM, Jonathan Marler wrote:
 Just because they are function attributes does not mean
 they were tokenized as "keywords".
The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.
I feel like I keep repeating myself so I'm just going to copy/paste.
 If the grammar supported decorating a function with a list of 
 id
tokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.
Right. That's was what I meant. Same thing could be possible for body...
Jan 26 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 26 January 2015 at 21:28:14 UTC, Foo wrote:
 On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler 
 wrote:
 On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright 
 wrote:
 On 1/26/2015 12:45 PM, Jonathan Marler wrote:
 Just because they are function attributes does not mean
 they were tokenized as "keywords".
The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.
I feel like I keep repeating myself so I'm just going to copy/paste.
 If the grammar supported decorating a function with a list of 
 id
tokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.
Right. That's was what I meant. Same thing could be possible for body...
Ya same thing applies to "body". I'm surprised no one has given a reason why it wasn't done this way.
Jan 26 2015
next sibling parent reply "Foo" <Foo test.de> writes:
On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote:
 On Monday, 26 January 2015 at 21:28:14 UTC, Foo wrote:
 On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler 
 wrote:
 On Monday, 26 January 2015 at 21:12:50 UTC, Walter Bright 
 wrote:
 On 1/26/2015 12:45 PM, Jonathan Marler wrote:
 Just because they are function attributes does not mean
 they were tokenized as "keywords".
The lexer has no idea what a function attribute is or that now it should be looking for attributes and then it should not be.
I feel like I keep repeating myself so I'm just going to copy/paste.
 If the grammar supported decorating a function with a list 
 of id
tokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. The lexer would recognize these attributes as normal ID tokens. The grammar could be amended to allow a function to be decorated with keywords and generic id tokens. Then the meaning of those tokens would be handled by semantic analysis. So the result would be that the lexer would see "nogc" and "safe" as normal id tokens (not keywords) which would be consumed as function attributes by the grammar. As far as I can tell this results in the best of both worlds. We can omit the ' ' character on function attributes like safe and nogc but they don't have to be added as keywords.
Right. That's was what I meant. Same thing could be possible for body...
Ya same thing applies to "body". I'm surprised no one has given a reason why it wasn't done this way.
Because you/we are community members and therefore "second-class citizens". If we suggest or discuss something, it is not that important. But if a small reddit post is made, it matters more. Look what happend to auto ref for non templates: community wants it but we don't get it.
Jan 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 2:15 PM, Foo wrote:
 Because you/we are community members and therefore "second-class citizens".
 If we suggest or discuss something, it is not that important. But if a small
 reddit post is made, it matters more.
Major contributors to D, like Don Clugston, advocated for it. It comes up repeatedly.
Jan 26 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 26 Jan 2015 17:56:00 -0800, Walter Bright wrote:

 On 1/26/2015 2:15 PM, Foo wrote:
 Because you/we are community members and therefore "second-class
 citizens". If we suggest or discuss something, it is not that
 important. But if a small reddit post is made, it matters more.
=20 Major contributors to D, like Don Clugston, advocated for it. =20 It comes up repeatedly.
and repeatedly rejected. and then... wow! silently accepted. without=20 discussion. D is not a community project. D is Walter Bright toy project.=
Jan 26 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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
Jan 28 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 1:25 PM, Jonathan Marler wrote:
 The lexer would recognize these attributes as normal ID tokens. The grammar
 could be amended to allow a function to be decorated with keywords and generic
 id tokens.  Then the meaning of those tokens would be handled by semantic
 analysis.
Not going to do that.
 So the result would be that the lexer would see "nogc" and "safe" as
 normal id tokens (not keywords) which would be consumed as function attributes
 by the grammar.  As far as I can tell this results in the best of both worlds.
 We can omit the ' ' character on function attributes like safe and nogc but
they
 don't have to be added as keywords.
I strongly dislike context sensitive tokens, whether or not they are done by the lexer or the parser or the semantic analysis. It's like using a nail for a cotter pin.
Jan 26 2015
next sibling parent zeljkog <zeljkog home.com> writes:
On 26.01.15 23:08, Walter Bright wrote:
 
 I strongly dislike context sensitive tokens, whether or not they are 
 done by the lexer or the parser or the semantic analysis.
 
 It's like using a nail for a cotter pin.
I remember the first time I read about D was something like "make language easier for compiler". It attracted me. (OK not only this :)
Jan 26 2015
prev sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 26 January 2015 at 22:09:44 UTC, Walter Bright wrote:
 On 1/26/2015 1:25 PM, Jonathan Marler wrote:
 The lexer would recognize these attributes as normal ID 
 tokens. The grammar
 could be amended to allow a function to be decorated with 
 keywords and generic
 id tokens.  Then the meaning of those tokens would be handled 
 by semantic
 analysis.
Not going to do that.
 So the result would be that the lexer would see "nogc" and 
 "safe" as
 normal id tokens (not keywords) which would be consumed as 
 function attributes
 by the grammar.  As far as I can tell this results in the best 
 of both worlds.
 We can omit the ' ' character on function attributes like safe 
 and nogc but they
 don't have to be added as keywords.
I strongly dislike context sensitive tokens, whether or not they are done by the lexer or the parser or the semantic analysis. It's like using a nail for a cotter pin.
Walter I hate to waste your time in answering my silly questions. I know you have a much deeper knowledge and understanding of the language then I. I can see that you believe my suggestion would create some unnecessary complexity ("It's like using a nail for a cotter pin"), however, I can't see how it would so I'm going to ask another question. I can see that you are trying to save time from your short responses so I'll understand if I understand if you feel I'm a lost cause and do not respond again. You said you strongly dislike "context-sensitive" tokens but I still don't know exactly what you mean by "context-sensitive". You said a token is "context-sensitive" if it is "A keyword in one context and an identifier in another". However, since I'm not proposing that "save" and "nogc" be keywords in any context, this doesn't appear to fall under your definition. So I must assume your real definition is more general. However, if the definition is too general then couldn't you consider almost any token "context-sensitive". For example, the token "static" or "ref" have different meanings depending on their context, so are they "context-sensitive"? Yes they are still keyword tokens, but "safe" and "nogc" would still just be regular id tokens so what makes "safe" and "nogc" more "context-sensitive" then "static" and "ref"? I'm honestly trying to understand. I can see from how the grammar works that you don't agree my solution is a good one, but I'm failing to understand why. I fail to see how allowing a function to be decorated with id tokens is more complex then only allowing keywords. Also sorry for harping on definitions, I majored in Computer Science and Mathematics...having strict definitions comes from my days of writing endless proofs.
Jan 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 3:07 PM, Jonathan Marler wrote:
 Walter I hate to waste your time in answering my silly questions.  I know you
 have a much deeper knowledge and understanding of the language then I.  I can
 see that you believe my suggestion would create some unnecessary complexity
 ("It's like using a nail for a cotter pin"), however, I can't see how it would
 so I'm going to ask another question. I can see that you are trying to save
time
 from your short responses so I'll understand if I understand if you feel I'm a
 lost cause and do not respond again.

 You said you strongly dislike "context-sensitive" tokens but I still don't know
 exactly what you mean by "context-sensitive". You said a token is
 "context-sensitive" if it is "A keyword in one context and an identifier in
 another".  However, since I'm not proposing that "save" and "nogc" be keywords
 in any context, this doesn't appear to fall under your definition.  So I must
 assume your real definition is more general. However, if the definition is too
 general then couldn't you consider almost any token "context-sensitive".  For
 example, the token "static" or "ref" have different meanings depending on their
 context, so are they "context-sensitive"?  Yes they are still keyword tokens,
 but "safe" and "nogc" would still just be regular id tokens so what makes
"safe"
 and "nogc" more "context-sensitive" then "static" and "ref"?

 I'm honestly trying to understand.  I can see from how the grammar works that
 you don't agree my solution is a good one, but I'm failing to understand why. 
I
 fail to see how allowing a function to be decorated with id tokens is more
 complex then only allowing keywords.  Also sorry for harping on definitions,  I
 majored in Computer Science and Mathematics...having strict definitions comes
 from my days of writing endless proofs.
Your argument boils down to there are no such things as token keywords. Yes, you can make a language work like that. I've seen it done. It is awful. The solution is clear: static is a keyword. You can NEVER use it as an identifier. Same with all other keywords.
Jan 26 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 27 January 2015 at 01:55:30 UTC, Walter Bright wrote:
 On 1/26/2015 3:07 PM, Jonathan Marler wrote:
 Walter I hate to waste your time in answering my silly 
 questions.  I know you
 have a much deeper knowledge and understanding of the language 
 then I.  I can
 see that you believe my suggestion would create some 
 unnecessary complexity
 ("It's like using a nail for a cotter pin"), however, I can't 
 see how it would
 so I'm going to ask another question. I can see that you are 
 trying to save time
 from your short responses so I'll understand if I understand 
 if you feel I'm a
 lost cause and do not respond again.

 You said you strongly dislike "context-sensitive" tokens but I 
 still don't know
 exactly what you mean by "context-sensitive". You said a token 
 is
 "context-sensitive" if it is "A keyword in one context and an 
 identifier in
 another".  However, since I'm not proposing that "save" and 
 "nogc" be keywords
 in any context, this doesn't appear to fall under your 
 definition.  So I must
 assume your real definition is more general. However, if the 
 definition is too
 general then couldn't you consider almost any token 
 "context-sensitive".  For
 example, the token "static" or "ref" have different meanings 
 depending on their
 context, so are they "context-sensitive"?  Yes they are still 
 keyword tokens,
 but "safe" and "nogc" would still just be regular id tokens so 
 what makes "safe"
 and "nogc" more "context-sensitive" then "static" and "ref"?

 I'm honestly trying to understand.  I can see from how the 
 grammar works that
 you don't agree my solution is a good one, but I'm failing to 
 understand why.  I
 fail to see how allowing a function to be decorated with id 
 tokens is more
 complex then only allowing keywords.  Also sorry for harping 
 on definitions,  I
 majored in Computer Science and Mathematics...having strict 
 definitions comes
 from my days of writing endless proofs.
Your argument boils down to there are no such things as token keywords. Yes, you can make a language work like that. I've seen it done. It is awful. The solution is clear: static is a keyword. You can NEVER use it as an identifier. Same with all other keywords.
This has become quite frustrating. I'm not sure how else to explain myself so maybe I'm just being dumb. Something inside me wants to explain myself again so I'll try one more time, if this fails, then it must be me not understanding your explanation and I'll give up. My proposal has nothing to do with keywords, it can be summarized with the following 2 steps: 1. Change the syntax of a function to allow it to be decorated with general id tokens. 2. Modify code generation to look at these new tokens and treat them as function attributes. I would suggest only allowing these id tokens to appear after the function arguments so as not to introduces any ambiguity in the grammar. void myfunc() pure safe nothrow nogc; pure (still a keyword, no change) safe (still NOT a keyword, no change) nothrow (stil a keyword, no change) nogc (still NOT a keyword, no change) My proposal is not trying making tokens "context-sensitive" by treating them as keywords sometimes and identifiers at other times. All it is doing is allowing an identifer token to be used as a function attribute. Nothing to do with keywords.
Jan 26 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 02:11:55 +0000, Jonathan Marler wrote:

 This has become quite frustrating.  I'm not sure how else to explain
 myself so maybe I'm just being dumb.
you are dumb. you can be dumb for some time, and then BANG! your proposal=20 is silently made "right". yet you're still dumb. that is The Way Of D.=
Jan 26 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 27 January 2015 at 07:50:36 UTC, ketmar wrote:
 On Tue, 27 Jan 2015 02:11:55 +0000, Jonathan Marler wrote:

 This has become quite frustrating.  I'm not sure how else to 
 explain
 myself so maybe I'm just being dumb.
you are dumb. you can be dumb for some time, and then BANG! your proposal is silently made "right". yet you're still dumb. that is The Way Of D.
"that is the way of D"...sad... I may have to agree with you on some of your points. Even after explaining my idea 3 or 4 times, it seemed to fall on deaf ears, or more specifically, uninterested ears that didn't try to understand. It's very frustrating when you take the time to write up an idea and no one bothers read it well enough to understand it, let alone take a few minutes to think about it. D is by far the best language I've worked with, but there's still work to be done. It has been quite disheartening when I try to discuss anything in the forums. People are very quick to respond to posts without fully reading them and the meat of the content gets lost in a slew of responses that miss the point. I'm not sure what I'm doing wrong or how this can be improved. But this pattern seems to keep happening no matter what topic is discussed. Not sure how to solve this...I'll think on this tomorrow.
Jan 27 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 08:30:43 +0000, Jonathan Marler wrote:

 On Tuesday, 27 January 2015 at 07:50:36 UTC, ketmar wrote:
 On Tue, 27 Jan 2015 02:11:55 +0000, Jonathan Marler wrote:

 This has become quite frustrating.  I'm not sure how else to explain
 myself so maybe I'm just being dumb.
you are dumb. you can be dumb for some time, and then BANG! your proposal is silently made "right". yet you're still dumb. that is The Way Of D.
=20 "that is the way of D"...sad... I may have to agree with you on some of your points. Even after explaining my idea 3 or 4 times, it seemed to fall on deaf ears, or more specifically, uninterested ears that didn't try to understand. It's very frustrating when you take the time to write up an idea and no one bothers read it well enough to understand it, let alone take a few minutes to think about it. D is by far the best language I've worked with, but there's still work to be done. It has been quite disheartening when I try to discuss anything in the forums. People are very quick to respond to posts without fully reading them and the meat of the content gets lost in a slew of responses that miss the point. I'm not sure what I'm doing wrong or how this can be improved. But this pattern seems to keep happening no matter what topic is discussed. Not sure how to solve this...I'll think on this tomorrow.
you just have to write alot of unpleasant things, and then you'll be=20 twitted by the most of the readers. and then you'll get no feedback on=20 your posts at all, but that means that you'll not get a negative feedback=20 too. for me it's amusing to see how my rants becoming "the things". and i know=20 that i can write anything i want to, 'cause almost nobody is reading my=20 posts anyway. but for this particular issue... i'm enraged by the fact that it was=20 commited without discussion at all. my ER got some controversal=20 reactions, and i was believe that anything controversal is discussed=20 first, and only then it may be accepted. but it looks like Walter is=20 don't care about D users, the only thing he cares of is "will this be=20 usable for me?" yes, i know that this is a "personal attack". and i know that it's a=20 project of Walter after all, so he can do anything he want to. but D is=20 the best language i've seen and used, that's why i'm so passionate about=20 it (and rude alot of times, i know). my only excuse is that (as i told)=20 that almost nobody is reading my posts. ;-)=
Jan 27 2015
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 27 January 2015 at 08:30:46 UTC, Jonathan Marler 
wrote:
  People are very quick to respond to posts without fully 
 reading them and the meat of the content gets lost in a slew of 
 responses that miss the point.  I'm not sure what I'm doing 
 wrong or how this can be improved.  But this pattern seems to 
 keep happening no matter what topic is discussed.  Not sure how 
 to solve this...I'll think on this tomorrow.
Isn't it more that one or two individuals don't get your point and keep arguing while the others got it? Anyway, the discussions on the rust dev list appears to be more educated than on the D forums, so maybe the people with a theoretical background gave up on D and was piqued by the potential given by linear typing? I think so... but they might get fed up with it eventually and in the mean time D has the opportunity to get the semantics right... From a political perspective it is better to leave the syntax as it is until the semantics of the language are frozen. If you keep changing the syntax then people will eventually be fed up with changes and it might be more difficult to push through a full redesign... Which in my opinion is needed. It is better to stay 25% flawed then eventually clean it up so that it is only 5% flawed, than to go from 25% bad to 20% bad to 15% and then people get fed up with changes and it is frozen at 15% flawed. The problem in the D community is that there is no planning. Syntax clean up should be a workgroup effort, not a metamorphic mutation process.
Jan 27 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 27 January 2015 at 09:18:19 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 27 January 2015 at 08:30:46 UTC, Jonathan Marler 
 wrote:
 People are very quick to respond to posts without fully 
 reading them and the meat of the content gets lost in a slew 
 of responses that miss the point.  I'm not sure what I'm doing 
 wrong or how this can be improved.  But this pattern seems to 
 keep happening no matter what topic is discussed.  Not sure 
 how to solve this...I'll think on this tomorrow.
Isn't it more that one or two individuals don't get your point and keep arguing while the others got it? Anyway, the discussions on the rust dev list appears to be more educated than on the D forums, so maybe the people with a theoretical background gave up on D and was piqued by the potential given by linear typing? I think so... but they might get fed up with it eventually and in the mean time D has the opportunity to get the semantics right... From a political perspective it is better to leave the syntax as it is until the semantics of the language are frozen. If you keep changing the syntax then people will eventually be fed up with changes and it might be more difficult to push through a full redesign... Which in my opinion is needed. It is better to stay 25% flawed then eventually clean it up so that it is only 5% flawed, than to go from 25% bad to 20% bad to 15% and then people get fed up with changes and it is frozen at 15% flawed. The problem in the D community is that there is no planning. Syntax clean up should be a workgroup effort, not a metamorphic mutation process.
Interesting points. Thanks for the response, it's a relief to hear people making sense :)
Jan 27 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 10:21:52 +0000, Jonathan Marler wrote:

 Interesting points.  Thanks for the response, it's a relief to hear
 people making sense :)
the funny thing is that Ola is a kind of "bad child" too. heh.=
Jan 27 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 27 January 2015 at 10:26:54 UTC, ketmar wrote:
 On Tue, 27 Jan 2015 10:21:52 +0000, Jonathan Marler wrote:

 Interesting points.  Thanks for the response, it's a relief to 
 hear
 people making sense :)
the funny thing is that Ola is a kind of "bad child" too. heh.
Hey, I have gray hairs in my beard! Show me sum respect, huh? I was a silent D forum lurker for... 7 years or so, waiting for a mature C++ replacement. Then decided to jump in and push for more planning and GC free programming support. We have nogc now, which is good, but that is about it. A simple statement like "D syntax will be reworked in 2016, lets form a working group" and "we need to define goals for GC, let us form a working group" would go a long way. But that would mean giving up control. Which Andrei and Walter are not going to do, so that means capable people will keep sitting on the fence (who wants to waste their time to have their efforts vetoed?) What is unfortunate is that the D heads keep adding features faster then the old ones can be fixed... Recently STL compatibility became an official goal and C++ exceptions... I say no more than this: I cant think of a single C++ library I would link to that would require that. With an orderly executed plan and feature freeze D could be production ready in 2-3 years. With no plan... multiply by at least 3, so we have 6-9 more years to wait assuming the feature set now is frozen... Nice, I have to go back to C++ now... C ya.
Jan 27 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 10:43:12 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 Hey, I have gray hairs in my beard!
me too!=
Jan 27 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 27 January 2015 at 10:47:23 UTC, ketmar wrote:
 On Tue, 27 Jan 2015 10:43:12 +0000, Ola Fosheim Grøstad wrote:

 Hey, I have gray hairs in my beard!
me too!
Coolies! *smooch*
Jan 27 2015
prev sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler wrote:
 The lexer would recognize these attributes as normal ID tokens.
  The grammar could be amended to allow a function to be 
 decorated with keywords and generic id tokens.  Then the 
 meaning of those tokens would be handled by semantic analysis.
How do you tell the difference between a return type and a user attribute on the left side? nogc myUda1 myUda2 returnType funcName() { return returnType(a); } They are UDAs only because they are not the second-to-last id (the return type) or the last id (the function name). How do you do 'auto' inferred return types in this context, when the compiler thinks your UDA is also your return type? Also, why burden the *programmer* with having to sort this out? It's too ambiguous to read, for my taste. If I just switch the names the entire signature changes: nogc returnType myUda1 myUda2 funcName() { return returnType(a); } Now it's supposed to return a myUda2, just because you switched the ordering? I can see why this idea would be rejected.
Jan 26 2015
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 26 January 2015 at 23:41:07 UTC, Zach the Mystic wrote:
 On Monday, 26 January 2015 at 21:25:57 UTC, Jonathan Marler 
 wrote:
 The lexer would recognize these attributes as normal ID tokens.
 The grammar could be amended to allow a function to be 
 decorated with keywords and generic id tokens.  Then the 
 meaning of those tokens would be handled by semantic analysis.
How do you tell the difference between a return type and a user attribute on the left side? nogc myUda1 myUda2 returnType funcName() { return returnType(a); } They are UDAs only because they are not the second-to-last id (the return type) or the last id (the function name). How do you do 'auto' inferred return types in this context, when the compiler thinks your UDA is also your return type? Also, why burden the *programmer* with having to sort this out? It's too ambiguous to read, for my taste. If I just switch the names the entire signature changes: nogc returnType myUda1 myUda2 funcName() { return returnType(a); } Now it's supposed to return a myUda2, just because you switched the ordering? I can see why this idea would be rejected.
I wasn't proposing UDA's to omit the ' ', only LDA's (Language defined attributes). Also, again, your example is assuming that we allow identifiers before the function signature, which is on optional part of what I proposed. The bigger problem with that proposal would be that if a function can start with a list of general id tokens, it's very likely to create ambiguity in the grammar. However, if they can only appear after the function signature, I'm almost certain no ambiguity is created. There are different ways to get around this, one is to require the ' ' only if the attribute appears before the function signature. The other is to disallow function attributes before the signature (or at least certain ones). There's different solutions, but that's not the point of the proposal. The point of the proposal is to Allow a function to be decorated with id tokens (so long as it doesn't create ambiguity) in order to specify attribute like "safe"/"nogc"/etc There are different ways to implement this and I see people arguing about specific implementations, but no one is addressing the main concept of the proposal (except Walter who just says that he doesn't like "context-sensitive" tokens but I fail to see how this creates tokens that are more "context-sensitive" then other tokens)
Jan 26 2015
prev sibling parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 01/26/15 20:43, Walter Bright via Digitalmars-d wrote:
 On 1/26/2015 8:13 AM, Foo wrote:
 You could do the same as C++ with override and final: they are only valid
 attributes if they appear _after_ the function/method. Elsewhere they are still
 valid as identifiers for e.g. variables.
Just 'no' on context-sensitive tokens.
C. C++. D. Windows. Pascal. System. exit. success. failure. artur
Jan 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 1:45 PM, Artur Skawina via Digitalmars-d wrote:
 C. C++. D. Windows. Pascal. System. exit. success. failure.
They're never keywords.
Jan 26 2015
parent Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 01/26/15 23:10, Walter Bright via Digitalmars-d wrote:
 On 1/26/2015 1:45 PM, Artur Skawina via Digitalmars-d wrote:
 Just 'no' on context-sensitive tokens.
C. C++. D. Windows. Pascal. System. exit. success. failure.
They're never keywords.
Hence, some other ones also don't really need to be keywords. Note I'm not arguing for/against these changes; just pointing out that there's precedent, as context sensitive magic identifiers already exist in D. Whether you want to call them "tokens" doesn't really matter (it's just an implementation detail). I actually would have preferred that they don't exist, but they do. artur
Jan 26 2015
prev sibling next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote:
 I agree with Jonathan's points, this solution doesn't seem like 
 an improvement.   If I understand the problem, we don't want to 
 make every attribute use the ' ' symbol because it looks bad 
 and would cause a lot of code changes for sake of consistency.  
 However, on the other hand, we don't want to support the new 
 properties because we have to add them as keywords which would 
 break code using those words and would make the language more 
 restrictive (nothing can be named nogc/safe/...).

 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?
Jan 26 2015
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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:
 I agree with Jonathan's points, this solution doesn't seem 
 like an improvement.   If I understand the problem, we don't 
 want to make every attribute use the ' ' symbol because it 
 looks bad and would cause a lot of code changes for sake of 
 consistency.  However, on the other hand, we don't want to 
 support the new properties because we have to add them as 
 keywords which would break code using those words and would 
 make the language more restrictive (nothing can be named 
 nogc/safe/...).

 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 wasn't saying that we should introduce ambiguity, I was saying we should be careful not to introduce ambiguity. I wrote that to indicate that I wasn't sure if the solution would introduce ambiguity or not. Zach suggested a solution that I'm fairly certain would be unambiguous (it's nice to have c++ people who've already seen the same problem know of a solution). By restricting the attributes to only appear after a function signature, it would also normalize the issue of consistent location of attributes, but this is another debate. However, allowing the attributes to appear before the function signature *might* work, but that would require much more care and may not even be possible (like I said, I'm not sure). A comprimize could be to allow attributes to omit the ' ' character if they appear after the function signature and require the ' ' character if they appear before. I'm not saying that's a good idea, just an option.
Jan 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler wrote:
 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 wasn't saying that we should introduce ambiguity, I was saying we should be careful not to introduce ambiguity. I wrote that to indicate that I wasn't sure if the solution would introduce ambiguity or not. Zach suggested a solution that I'm
I think you meant someone else!
 fairly certain would be unambiguous (it's nice to have c++ 
 people who've already seen the same problem know of a 
 solution).  By restricting the attributes to only appear after 
 a function signature, it would also normalize the issue of 
 consistent location of attributes, but this is another debate.  
 However, allowing the attributes to appear before the function 
 signature *might* work, but that would require much more care 
 and may not even be possible (like I said, I'm not sure).
I don't think it is possible. Any non-keyword identifier is assumed to be the return type of the function. It all has to be solved in the parsing phase. You can't wait till semantic analysis to figure out what's a return type and what's an attribute. This is why D compiles so fast, because all phases of compilation are distinct.
Jan 26 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 26 January 2015 at 22:04:48 UTC, Zach the Mystic wrote:
 On Monday, 26 January 2015 at 21:37:43 UTC, Jonathan Marler 
 wrote:
 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 wasn't saying that we should introduce ambiguity, I was saying we should be careful not to introduce ambiguity. I wrote that to indicate that I wasn't sure if the solution would introduce ambiguity or not. Zach suggested a solution that I'm
I think you meant someone else!
 fairly certain would be unambiguous (it's nice to have c++ 
 people who've already seen the same problem know of a 
 solution).  By restricting the attributes to only appear after 
 a function signature, it would also normalize the issue of 
 consistent location of attributes, but this is another debate.
  However, allowing the attributes to appear before the 
 function signature *might* work, but that would require much 
 more care and may not even be possible (like I said, I'm not 
 sure).
I don't think it is possible. Any non-keyword identifier is assumed to be the return type of the function. It all has to be solved in the parsing phase. You can't wait till semantic analysis to figure out what's a return type and what's an attribute. This is why D compiles so fast, because all phases of compilation are distinct.
Copy/Paste:
 solution).  By restricting the attributes to only appear after 
 a function signature, it would also normalize the issue of 
 consistent location of attributes, but this is another debate.
The return type doesn't appear after the function signature.
Jan 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 23:32:59 UTC, Jonathan Marler wrote:
 Copy/Paste:

 solution).  By restricting the attributes to only appear 
 after a function signature, it would also normalize the issue 
 of consistent location of attributes, but this is another 
 debate.
The return type doesn't appear after the function signature.
Yes it *is* another debate. Now you can't add attributes at the beginning: // no can do anymore nogc pure myUda retType funcName() { ... } // must do this instead retType funcName() nogc pure myUdal { } You're suggesting canceling a whole style of labeling a function, aren't you? It's a big change. I wouldn't accept it unless it demonstrated a clear advantage. In fact, maybe it *can* demonstrate such, having all D functions be uniform in how their attributes are written, but you'll need a whole new thread and a DIP, and personally I don't see this carrying its weight.
Jan 26 2015
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 26 January 2015 at 23:50:12 UTC, Zach the Mystic wrote:
 On Monday, 26 January 2015 at 23:32:59 UTC, Jonathan Marler 
 wrote:
 Copy/Paste:

 solution).  By restricting the attributes to only appear 
 after a function signature, it would also normalize the 
 issue of consistent location of attributes, but this is 
 another debate.
The return type doesn't appear after the function signature.
Yes it *is* another debate. Now you can't add attributes at the beginning: // no can do anymore nogc pure myUda retType funcName() { ... } // must do this instead retType funcName() nogc pure myUdal { } You're suggesting canceling a whole style of labeling a function, aren't you? It's a big change. I wouldn't accept it unless it demonstrated a clear advantage. In fact, maybe it *can* demonstrate such, having all D functions be uniform in how their attributes are written, but you'll need a whole new thread and a DIP, and personally I don't see this carrying its weight.
http://en.wikipedia.org/wiki/Straw_man I'm not proposing that we don't allow attributes before a function, I was mentioning an idea related to my proposal. I agree with everything you said, you're just not addressing the proposal itself (see the link).
Jan 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 23:53:22 UTC, Jonathan Marler wrote:
 http://en.wikipedia.org/wiki/Straw_man

 I'm not proposing that we don't allow attributes before a 
 function, I was mentioning an idea related to my proposal.  I 
 agree with everything you said, you're just not addressing the 
 proposal itself (see the link).
Show code examples of how it would work. I can't guess anymore what you're proposing.
Jan 26 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Monday, 26 January 2015 at 23:55:55 UTC, Zach the Mystic wrote:
 On Monday, 26 January 2015 at 23:53:22 UTC, Jonathan Marler 
 wrote:
 http://en.wikipedia.org/wiki/Straw_man

 I'm not proposing that we don't allow attributes before a 
 function, I was mentioning an idea related to my proposal.  I 
 agree with everything you said, you're just not addressing the 
 proposal itself (see the link).
Show code examples of how it would work. I can't guess anymore what you're proposing.
Haha, ok, sorry for being too abstract. I think a safe way to implement my proposal would be to do what c++ did and only allow non-keyword function attributes to omit the ' ' symbol if they appear after the function signature: 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) If the initial proposal is accepted by people, then we can talk about the other examples, but let's focus on the proposal before focusing on sub-proposals.
Jan 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler 
wrote:
 Haha, ok, sorry for being too abstract.

 I think a safe way to implement my proposal would be to do what 
 c++ did and only allow non-keyword function attributes to omit 
 the ' ' symbol if they appear after the function signature:

 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)

 If the initial proposal is accepted by people, then we can talk 
 about the other examples, but let's focus on the proposal 
 before focusing on sub-proposals.
Alright, good. However... I'm still against it. Firstly, in my first comment in the current thread, http://forum.dlang.org/post/uimpnhiweuitnnbeqshu forum.dlang.org ...I made a list of considerations, among which: 3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without ` `. This alone puts me at next to zero for your proposal in terms of benefit. It will strike people as a strange and unnecessary exception to the way to mark their attributes, for the sake of a slight beautification of only those cases where the attributes come after the signature. Consider me an old-fashioned "a keyword is a keyword is a keyword" kind of guy. Yes, there are outliers (C++, D, exit, success, etc.), but I don't see why that list should be expanded, as it is nicely contained, IMO.
Jan 26 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic 
wrote:
 On Tuesday, 27 January 2015 at 00:05:17 UTC, Jonathan Marler 
 wrote:
 Haha, ok, sorry for being too abstract.

 I think a safe way to implement my proposal would be to do 
 what c++ did and only allow non-keyword function attributes to 
 omit the ' ' symbol if they appear after the function 
 signature:

 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)

 If the initial proposal is accepted by people, then we can 
 talk about the other examples, but let's focus on the proposal 
 before focusing on sub-proposals.
Alright, good. However... I'm still against it. Firstly, in my first comment in the current thread, http://forum.dlang.org/post/uimpnhiweuitnnbeqshu forum.dlang.org ...I made a list of considerations, among which: 3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without ` `. This alone puts me at next to zero for your proposal in terms of benefit. It will strike people as a strange and unnecessary exception to the way to mark their attributes, for the sake of a slight beautification of only those cases where the attributes come after the signature. Consider me an old-fashioned "a keyword is a keyword is a keyword" kind of guy. Yes, there are outliers (C++, D, exit, success, etc.), but I don't see why that list should be expanded, as it is nicely contained, IMO.
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? void myfunc() pure safe nothrow nogc; void myfunc() pure safe nothrow nogc; This will inevitably result in someone writing this: pure safe nothrow nogc void myfunc(); which would still be invalid in this proposal, and I think this is still a problem but not a huge one since this is easily caught by the compiler.
Jan 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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.
 void myfunc() pure  safe nothrow  nogc;
 void myfunc() pure safe nothrow nogc;

 This will inevitably result in someone writing this:

 pure safe nothrow nogc void myfunc();

 which would still be invalid in this proposal, and I think this 
 is still a problem but not a huge one since this is easily 
 caught by the compiler.
This will annoy people even more than they are already annoyed by the ` `-on-some-attributes-and-not-others inconsistency. The latter type (type 2 in my first thread) already exists in the language, but it shoudln't be replaced by another type. This argument was already made by Jonathan Davis.
Jan 26 2015
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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.
 void myfunc() pure  safe nothrow  nogc;
 void myfunc() pure safe nothrow nogc;

 This will inevitably result in someone writing this:

 pure safe nothrow nogc void myfunc();

 which would still be invalid in this proposal, and I think 
 this is still a problem but not a huge one since this is 
 easily caught by the compiler.
This will annoy people even more than they are already annoyed by the ` `-on-some-attributes-and-not-others inconsistency. The latter type (type 2 in my first thread) already exists in the language, but it shoudln't be replaced by another type. This argument was already made by Jonathan Davis.
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. I proposed that we ADD another way of writing attributes, however, my proposal doesn't require that we ADD another way, instead, we can REPLACE the current way of writing attributes by normalizing where they appear. However, like I said, you have to choose one or the other, broken code or inconsistency. The nice part about ADDING another way of writing attributes is that the hope is that the inconsistency will be solved in the future. Changing the way to write attributes will introduce more inconsistency at first. However, the hope is that if the new way is "better" or looks "nicer", then developers will hopefully consistently choose the new way. Then, if there's no reason to keep the old way, it can be deprecated and the consistency issue is solved. 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.
Jan 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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. :-)
Jan 26 2015
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
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.
Jan 26 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Jan 28 2015
prev sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 23:50:12 UTC, Zach the Mystic wrote:
 Yes it *is* another debate. Now you can't add attributes at the 
 beginning:

 // no can do anymore
 nogc pure myUda
 retType funcName() {
    ...
 }

 // must do this instead
 retType funcName() nogc pure myUdal {
 }

 You're suggesting canceling a whole style of labeling a 
 function, aren't you? It's a big change. I wouldn't accept it 
 unless it demonstrated a clear advantage. In fact, maybe it 
 *can* demonstrate such, having all D functions be uniform in 
 how their attributes are written, but you'll need a whole new 
 thread and a DIP, and personally I don't see this carrying its 
 weight.
Also, aren't attribute blocks made impossible by this?: nogc: auto myFunc() { ... } auto myOtherFunc() { ... }
Jan 26 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
 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?
There is no ambiguity in "object.body" or even "object.if = 42"... All you need is an escape mechanism in the definition. The reason for why you want this is that you interoperate with external interfacing definitions and standards that you auto generate D code from. It is not likely that the external world (like governments who define record exchange standards) will adapt their naming policies to D idiocracies. If you cannot use "body" as a field name then you cannot implement the HTML5 DOM according to the standard.
Jan 26 2015
parent reply "ZombineDev" <valid_email he.re> writes:
That's what pragma(mangle, "...")[1] is for. It is used at least 
a couple of times in druntime (and probably elsewhere - e.g. in 
library bindings).

[1]: http://dlang.org/pragma.html (at the bottom of the page)


On Monday, 26 January 2015 at 21:56:20 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic 
 wrote:
 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?
There is no ambiguity in "object.body" or even "object.if = 42"... All you need is an escape mechanism in the definition. The reason for why you want this is that you interoperate with external interfacing definitions and standards that you auto generate D code from. It is not likely that the external world (like governments who define record exchange standards) will adapt their naming policies to D idiocracies. If you cannot use "body" as a field name then you cannot implement the HTML5 DOM according to the standard.
Jan 26 2015
parent "ZombineDev" <valid_email he.re> writes:
Examples:

[1]: 
https://github.com/D-Programming-Language/druntime/blob/2024ca6d3e29362a2fc84ef51c0f73316259d645/src/core/internal/traits.d#L57

[2]: 
https://github.com/D-Programming-Language/phobos/blob/de5d3392782c85e79e71e257b3ba607ccff852a5/std/typecons.d#L3240

On Monday, 26 January 2015 at 22:02:44 UTC, ZombineDev wrote:
 That's what pragma(mangle, "...")[1] is for. It is used at 
 least a couple of times in druntime (and probably elsewhere - 
 e.g. in library bindings).

 [1]: http://dlang.org/pragma.html (at the bottom of the page)


 On Monday, 26 January 2015 at 21:56:20 UTC, Ola Fosheim Grøstad 
 wrote:
 On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic 
 wrote:
 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?
There is no ambiguity in "object.body" or even "object.if = 42"... All you need is an escape mechanism in the definition. The reason for why you want this is that you interoperate with external interfacing definitions and standards that you auto generate D code from. It is not likely that the external world (like governments who define record exchange standards) will adapt their naming policies to D idiocracies. If you cannot use "body" as a field name then you cannot implement the HTML5 DOM according to the standard.
Jan 26 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Jan 28 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-01-26 17:10, Jonathan Marler wrote:
 I agree with Jonathan's points, this solution doesn't seem like an
 improvement.   If I understand the problem, we don't want to make every
 attribute use the ' ' symbol because it looks bad and would cause a lot
 of code changes for sake of consistency. However, on the other hand, we
 don't want to support the new properties because we have to add them as
 keywords which would break code using those words and would make the
 language more restrictive (nothing can be named nogc/safe/...).

 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.
We could use compiler recognized UDA's. It's not complicated, at least no in the case I've implemented it. -- /Jacob Carlborg
Jan 26 2015
prev sibling next sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:
 In theory, the increased consistency is welcome, but the increased visual
 noise definitely is not.  And if we leave in pure and nothrow without  ,
 then we're going to have code out there doing both, which adds to the
 confusion, and if we deprecate pure and nothrow without  , then we'll be
 forced to change pretty much every D program in existence.
Only if the deprecation became an error.
 But It's not like this really improves consistency all that much anyway,
 because public, protected, package, private, final, override, static, const,
 immutable, inout, and deprecated all don't have  .
Most of those also apply to variable members. pure, nothrow, return only apply to functions. I like this change, but it might be better if final, override and inout gained attribute syntax too. Then it would have more consistency. Also the inverted-attribute option then doesn't need !ugly !sigils - impure vs pure, throw vs nothrow, etc.
 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.
Jan 26 2015
next sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 26/01/2015 17:07, Nick Treleaven wrote:
 and inout gained  attribute syntax too
Actually inout can apply to local variables, so it shouldn't have a ' ' by my logic.
Jan 26 2015
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Jan 26 2015
parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
 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.
But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
Jan 27 2015
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:
 On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
 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.
But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have on them to avoid requiring a keyword (which is why we have on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart. IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have and which don't, or we shouldn't mess with them. Honestly, I just consider to be part of the name, and I memorized it as part of the keyword. The result is that I don't even remember ever having a problem trying to figure out which attributes had and which didn't. Sure, it would be nice we had a rule of thumb that we could give newbies that would tell them which to use, but so few have that I really don't think that it's much of a practical issue - just an aesthetic one. I'd also point out that the compiler will give an error message telling you which attributes have on them you use something like deprecated, so it's not hard at all to figure out what you did wrong. So, even if someone has trouble remembering which built-in attributes start with , they'll figure out where they got it wrong quite quickly. - Jonathan M Davis
Jan 27 2015
next sibling parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 27 January 2015 at 16:50:00 UTC, Jonathan M Davis 
wrote:
 On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via 
 Digitalmars-d wrote:
 On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
 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.
But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have on them to avoid requiring a keyword (which is why we have on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart. IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have and which don't, or we shouldn't mess with them. Honestly, I just consider to be part of the name, and I memorized it as part of the keyword. The result is that I don't even remember ever having a problem trying to figure out which attributes had and which didn't. Sure, it would be nice we had a rule of thumb that we could give newbies that would tell them which to use, but so few have that I really don't think that it's much of a practical issue - just an aesthetic one. I'd also point out that the compiler will give an error message telling you which attributes have on them you use something like deprecated, so it's not hard at all to figure out what you did wrong. So, even if someone has trouble remembering which built-in attributes start with , they'll figure out where they got it wrong quite quickly. - Jonathan M Davis
I share your sentiments exactly. The only thing I would add is that I don't see why we can't just remove the ' ' symbol from all language defined function attributes. I've already proposed a way to do this that wouldn't add any more keywords and would be fairly trivial to do (see my previous posts). However, since Walter doesn't like my idea I guess it's dead. However, I can't figure out why he doesn't like it...so. This issue isn't a huge deal, like you said it's not too hard to learn which ones require the ' ' symbol and which ones don't, it just looks weird. It's just too bad that my solution isn't even considered even though it would solve all these issues.
Jan 27 2015
prev sibling next sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
 abstract also applies to classes, as does final.
Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.
 Also, if we end up adding
 any new attributes later, they're bound to have   on them to avoid requiring
 a keyword (which is why we have   on some of them in the first place), and
 if the new attribute applies to variables or types as well, then the
 division that you're suggesting falls apart.
It's inspired from the status quo - there are no attributes that apply to variables. __gshared uses underscores instead of attribute syntax. If we want to introduce a new attribute that applies to both functions and variables, use __attribute.
Jan 27 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote:
 On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
 abstract also applies to classes, as does final.
Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.
I think you may have missed the point. I believe what Jonathan is saying is that if you turn abstract into abstract then you have to consider how to solve the "abstract class" issue. Do you change it to: abstract class ? Same thing with final. Since the same keywords are used in a lot of different contexts, if you change how it is used in one context then it's going to be inconsistent with how it's used in the other contexts (like with a function or a class). Then if you want consistency (which is the point of why we are discussing this change in the first place) you have to change every context it is used in. If you follow through with your proposal, you'll end up putting a ' ' character before almost every keyword in the language which has no benefit since the ' ' symbol serves no useful purpose to the compiler in the first place (on a keyword at least).
Jan 27 2015
parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 27/01/2015 18:01, Jonathan Marler wrote:
 On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote:
 On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
 abstract also applies to classes, as does final.
Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.
I think you may have missed the point. I believe what Jonathan is saying is that if you turn abstract into abstract then you have to consider how to solve the "abstract class" issue. Do you change it to: abstract class ?
Yes, because it affects the class's functions, not its variable members.
 Same thing with final.  Since the same keywords are used in a lot of
 different contexts, if you change how it is used in one context then
 it's going to be inconsistent with how it's used in the other contexts
 (like with a function or a class).  Then if you want consistency (which
 is the point of why we are discussing this change in the first place)
 you have to change every context it is used in. If you follow through
 with your proposal, you'll end up putting a ' ' character before almost
 every keyword in the language
In that case I don't think you've really grokked my proposal. It only requires 5 changes to attributes for consistency (and that's counting pure and nothrow).
Jan 27 2015
next sibling parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 27 January 2015 at 18:21:37 UTC, Nick Treleaven wrote:
 On 27/01/2015 18:01, Jonathan Marler wrote:
 On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven 
 wrote:
 On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote:
 abstract also applies to classes, as does final.
Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable.
I think you may have missed the point. I believe what Jonathan is saying is that if you turn abstract into abstract then you have to consider how to solve the "abstract class" issue. Do you change it to: abstract class ?
Yes, because it affects the class's functions, not its variable members.
 Same thing with final.  Since the same keywords are used in a 
 lot of
 different contexts, if you change how it is used in one 
 context then
 it's going to be inconsistent with how it's used in the other 
 contexts
 (like with a function or a class).  Then if you want 
 consistency (which
 is the point of why we are discussing this change in the first 
 place)
 you have to change every context it is used in. If you follow 
 through
 with your proposal, you'll end up putting a ' ' character 
 before almost
 every keyword in the language
In that case I don't think you've really grokked my proposal. It only requires 5 changes to attributes for consistency (and that's counting pure and nothrow).
Problem Summary: Using an ' ' symbol for some function attributes and not others is weird. void foo() pure safe const; Current Reason: keywords don't use a ' ' and non-keywords use a ' ' Your Solution: Have attributes that apply to variables use no ' ' and all other attributes use a ' '. You've changed the cutoff from "keywords" to "whether or not they apply to variables". How does this solve the original problem (stated above)? void foo() pure safe const; // OR public pure final safe foo(); How is this more consistent? This doesn't solve the problem is just shuffles around the cases when we use ' ' and when we don't. Note: not to mention that it still looks horrible to use ' '. There's no reason the language needs to require a ' ' on a keyword. The only reason is to make things consistent but if you're not making things more consistent, as shown above.
Jan 27 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 27 January 2015 at 18:21:37 UTC, Nick Treleaven wrote:
 I think you may have missed the point.  I believe what 
 Jonathan is
 saying is that if you turn abstract into  abstract then you 
 have to
 consider how to solve the "abstract class" issue.  Do you 
 change it to:

  abstract class ?
Yes, because it affects the class's functions, not its variable members.
Probably unimportant, but no, abstract and final apply to classes, not to members. tl;dr what's problem with applying attributes to classes? Classes can have various attributes, abstract and final are just among them. I would recommend this formatting: --- abstract final notypeinfo class ... ---
Jan 28 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-01-27 17:49, Jonathan M Davis via Digitalmars-d wrote:

 IMHO, if we have to search for a way to make them consistent, then there's
 no point. We're just going to end up with making things more consistent in
 one way and less in another without necessarily making it any easier for
 anyone to keep track of, so we'd just be shuffling things around. I think
 that there needs to be a clear and solid benefit to changing which
 attributes have   and which don't, or we shouldn't mess with them.
We could change all attributes to be compiler recognized UDA's, which would require prefixing them with . All current attributes would be removed. This is of course a major breaking change and will not happen. Since they would be UDA's it would be possible to disambiguate with other UDA's with the same name in another module. -- /Jacob Carlborg
Jan 27 2015
prev sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Jonathan M Davis via Digitalmars-d píše v Út 27. 01. 2015 v 08:49 -0800:
 On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via Digitalmars-d wrote:
 On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote:
 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.
But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have on them to avoid requiring a keyword (which is why we have on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart. IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have and which don't, or we shouldn't mess with them.
Exactly I do not think we can (want to) be 100% consistent . Even If I really like to see every attribute to be with or without (because consistency). I do not think it will be perfect. For eg. one of things I rewrite some of my code from PHP consist with following steps: 1.) remove $ 2.) replace :: and -> for . 3.) some minor changes (sometimes nothing) So I would prefer if private, public, protected, final, static stay without , but D specific things like pure,immutable,nothrow,nogc,safe,trust,disable,deprecated... would go with if I speak about immutable(const) I only mean function attribut not storage. And It would be perfect if all theese must be on the right side: // OK public final void someFunc() immutable safe nogc nothrow { } // OK public final immutable(int) someFunc() immutable safe nogc nothrow { return 5 } // Deprecated public final immutable int someFunc() immutable safe nogc nothrow { return 5 } // Error or Deprecated public final immutable int someFunc() safe nogc nothrow { return 5 }
Jan 27 2015
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Tuesday, 27 January 2015 at 21:15:16 UTC, Daniel Kozak wrote:
 Jonathan M Davis via Digitalmars-d píše v Út 27. 01. 2015 v 
 08:49 -0800:
 On Tuesday, January 27, 2015 11:47:04 Nick Treleaven via 
 Digitalmars-d wrote:
 On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d 
 wrote:
 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.
But I explained that most function attributes don't only apply to functions but to variables as well: public, protected, package, private, static, const, immutable, inout, and deprecated So it can be consistent that the above don't use . These only affect functions, not variables, so should be attributes IMO: final, override, abstract These affect both: return, ref So if we want some kind of consistency, we can achieve it by adding for final, override, abstract, and removing it for 'return'.
abstract also applies to classes, as does final. Also, if we end up adding any new attributes later, they're bound to have on them to avoid requiring a keyword (which is why we have on some of them in the first place), and if the new attribute applies to variables or types as well, then the division that you're suggesting falls apart. IMHO, if we have to search for a way to make them consistent, then there's no point. We're just going to end up with making things more consistent in one way and less in another without necessarily making it any easier for anyone to keep track of, so we'd just be shuffling things around. I think that there needs to be a clear and solid benefit to changing which attributes have and which don't, or we shouldn't mess with them.
Exactly I do not think we can (want to) be 100% consistent . Even If I really like to see every attribute to be with or without (because consistency). I do not think it will be perfect. For eg. one of things I Even rewrite some of my code from PHP consist with following steps: 1.) remove $ 2.) replace :: and -> for . 3.) some minor changes (sometimes nothing) So I would prefer if private, public, protected, final, static stay without , but D specific things like pure,immutable,nothrow,nogc,safe,trust,disable,deprecated... would go with if I speak about immutable(const) I only mean function attribut not storage. And It would be perfect if all theese must be on the right side: // OK public final void someFunc() immutable safe nogc nothrow { } // OK public final immutable(int) someFunc() immutable safe nogc nothrow { return 5 } // Deprecated public final immutable int someFunc() immutable safe nogc nothrow { return 5 } // Error or Deprecated public final immutable int someFunc() safe nogc nothrow { return 5 }
Good idea. The only think I would change is when an attribute appears on the right side, why not omit the ' ' symbol :) Other then that I like the consistency of putting the attributes in the same place. But even if you kept the ' ' symbol I would still prefer your proposal over what we have now. It's more consistent and no longer looks weird. When someone new comes along it makes sense and doesn't look like a hack.
Jan 27 2015
prev sibling next sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:
 the increased visual
 noise definitely is not.
Being able to ignore things starting with is useful when reading function signatures: property const(T) pure nothrow foo(Arg arg, T bar) const ... So can actually be signal rather than noise.
Jan 26 2015
prev sibling next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis 
wrote:
 Personally, I'd much prefer that we not make this change. It's 
 just
 shuffling things around in an attempt to make them more 
 consistent while
 actually making them _less_ consistent.

 - Jonathan M Davis
I don't think this problem is solvable without "dfix". Here are the factors I would consider: 1. ` ` is ugly. Therefore it would be great to make `safe`, `trusted`, `system`, and `nogc` full-fledged keywords, to spare future readers of code all those ` `s. So long as it's definitely a permanent feature of the language, it should look as good as possible. (`property` too, if we're sure it's not leaving). ` ` is then left exclusively for UDAs, an improvement, IMO. 2. Consistency of attribute usage is important. All built-in attributes should be markable in the same way, either with, or without an ` ` sign. 3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without ` `. 4. Old code matters. Existing code puts points 2 and 3 into conflict. Now it goes without saying that changing old code is a nuisance. But it's important to point out that not all code changes are the same. In the interest of furthering this discussion, here is a list of the types of breaking changes, in my order of least to most desirable: B1. Silent breaking changes. Same code now does different things. Rightly regarded as the worst kind. You don't even know what hit you. B2. Completely pointless changes. For the record, I'm against changes which literally have no benefit. Most changes which get seriously discussed, however, involve difficult tradeoffs, for which the assumed benefit must outweigh the perceived loss, plus the "switching costs". The point of this list is to emphasize that not all switching costs are the same, and that they depend greatly on the *individual* change. B3. Breaking changes which require significant redesign of code. Sociomantic faces this issue with their move to D2. B4. Changes which can easily be fixed, with the right know-how. Great error messages, referring the user to the documentation of these changes and how to fix them, is essential. B5. The kind that a tool such as 'dfix', can automate. 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. B6. Changes which catch existing bugs, with no false positives. Obviously wins. The changes suggested in this thread are of kind 5.5. But more people would have to get behind the whole 'dfix' approach for it to work. "Most D code is yet to be written. #PleaseBreakOurCode." +1
Jan 26 2015
next sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 19:02:27 UTC, Zach the Mystic wrote:
 The changes suggested in this thread are of kind 5.5.
s/5.5/B5
Jan 26 2015
prev sibling parent "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
"5. The kind that a tool such as 'dfix', can automate. 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.
"

Sorry for the tangent (I have no view on the major topic),  +1 
for including a link to dfix within the compiler.  Repetitive 
things ought to be automated and made easy and how many times 
does one end up fixing up old code ?
Jan 26 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 26 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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. T -- If it tastes good, it's probably bad for you.
Jan 26 2015
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Jan 28 2015
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
It was sad that calls for more breakage were mostly ignored. But 
there is one thing now that is even worse - referring to 
#pleasebreakmycode as an excuse to introduce random changes based 
on random reddit comment - and completely dismissing everything 
that was said on topic initially. Resulting in exactly the 
opposite action that was asked to.

Please, revert this PR asap. After that it can possibly be 
introduced after meeting necessary prerequisites:

1) explanation of problem it fixes
2) design rationale for new model
3) evaluation of ROI
4) tools for simple migration - either as part of dfix or compiler

This is absolutely mandatory list for any change of language 
fundamentals to be considered legitimate.
Jan 26 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 12:26 PM, Dicebot wrote:
 It was sad that calls for more breakage were mostly ignored. But there is one
 thing now that is even worse - referring to #pleasebreakmycode as an excuse to
 introduce random changes based on random reddit comment - and completely
 dismissing everything that was said on topic initially. Resulting in exactly
the
 opposite action that was asked to.
I can't find Don's original post on the topic.
Jan 26 2015
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Monday, 26 January 2015 at 20:56:36 UTC, Walter Bright wrote:
 On 1/26/2015 12:26 PM, Dicebot wrote:
 It was sad that calls for more breakage were mostly ignored. 
 But there is one
 thing now that is even worse - referring to #pleasebreakmycode 
 as an excuse to
 introduce random changes based on random reddit comment - and 
 completely
 dismissing everything that was said on topic initially. 
 Resulting in exactly the
 opposite action that was asked to.
I can't find Don's original post on the topic.
Donno If you are referring to this [1], but at least it's about this pull... --- Paolo [1] http://forum.dlang.org/thread/bug-13388-3 https.issues.dlang.org%2F?page=3#post-mailman.312.1409643575.5783.digitalmars-d-bugs:40puremagic.com
Jan 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 1:07 PM, Paolo Invernizzi wrote:
 On Monday, 26 January 2015 at 20:56:36 UTC, Walter Bright wrote:
 On 1/26/2015 12:26 PM, Dicebot wrote:
 It was sad that calls for more breakage were mostly ignored. But there is one
 thing now that is even worse - referring to #pleasebreakmycode as an excuse to
 introduce random changes based on random reddit comment - and completely
 dismissing everything that was said on topic initially. Resulting in exactly
the
 opposite action that was asked to.
I can't find Don's original post on the topic.
Donno If you are referring to this [1], but at least it's about this pull... [1] http://forum.dlang.org/thread/bug-13388-3 https.issues.dlang.org%2F?page=3#post-mailman.312.1409643575.5783.digitalmars-d-bugs:40puremagic.com
Yup, that's it. Your search-foo is better than mine! A more direct link: https://issues.dlang.org/show_bug.cgi?id=13388#c27
Jan 26 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 26 January 2015 at 21:17:50 UTC, Walter Bright wrote:
 Donno If you are referring to this [1], but at least it's 
 about this pull...
 [1]
 http://forum.dlang.org/thread/bug-13388-3 https.issues.dlang.org%2F?page=3#post-mailman.312.1409643575.5783.digitalmars-d-bugs:40puremagic.com
Yup, that's it. Your search-foo is better than mine! A more direct link: https://issues.dlang.org/show_bug.cgi?id=13388#c27
I was referring to earlier posts (as old as Don's dconf 2013 talk ;)) However my complaint is not about the change itself (though I personally disagree with Don reasoning in that issue, it is a delicate matter) but about the fact that it is again done as a casual PR and our breaking change culture does not seem to change : it is still all or nothing approach. No automatic migration tools, no easily found rationale / explanation, no posts in D.announce - just an ordinary commit. No wonder any of more notable change is considered that scary.
Jan 26 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 1:29 PM, Dicebot wrote:
 However my complaint is not about the change itself (though I personally
 disagree with Don reasoning in that issue, it is a delicate matter) but about
 the fact that it is again done as a casual PR and our breaking change culture
 does not seem to change : it is still all or nothing approach. No automatic
 migration tools, no easily found rationale / explanation, no posts in
D.announce
 - just an ordinary commit. No wonder any of more notable change is considered
 that scary.
What I wanted by doing this is to produce some sort of consensus. The topic has already been discussed to death.
Jan 26 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-26 23:04, Walter Bright wrote:

 What I wanted by doing this is to produce some sort of consensus. The
 topic has already been discussed to death.
You have complained that one of your old D1 projects didn't compile with the latest D2 compiler. How would you expect that to still compile when making changes like this and without those things Dicebot mentioned. -- /Jacob Carlborg
Jan 27 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/27/2015 2:14 AM, Jacob Carlborg wrote:
 You have complained that one of your old D1 projects didn't compile with the
 latest D2 compiler. How would you expect that to still compile when making
 changes like this and without those things Dicebot mentioned.
This change didn't break a single line in the libraries or the test suite.
Jan 27 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 27 January 2015 at 10:50:53 UTC, Walter Bright wrote:
 This change didn't break a single line in the libraries or the 
 test suite.
Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. It is simply moving things around for the sake of marking some bugzilla report as closed - there is no consistent rationale for applying to attributes available. Just the fact that change can't possibly break anything doesn't mean it is can't have negative value. It _may_ have some well-though rationale behind I am failing to spot but that is not presented to users in any way.
Jan 28 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:

 Yes, but it didn't also fix anything, only introduced more ways 
 to do the same thing - without any plans for some consistent 
 model.
One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it. The word "obvious" is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-) Bye, bearophile
Jan 28 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 28 January 2015 at 13:14:16 UTC, bearophile wrote:
 Dicebot:

 Yes, but it didn't also fix anything, only introduced more 
 ways to do the same thing - without any plans for some 
 consistent model.
One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it. The word "obvious" is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-)
I am aware of Python Zen and generally it is not applicable to D. Multiple ways of doing the same thing can be justified both for backwards compatibility and pragmatical reason. But in this case I see no improvement that could justify it. I'd welcome the change to attribute syntax but only one that actually fixes the problems and not just rearranges things.
Jan 28 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
 But in this case I see no improvement that could justify it.
Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388
Jan 28 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote:
 On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
 But in this case I see no improvement that could justify it.
Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388
Yes, but as it has been already mentioned in this thread new system is as much inconsistent - it simply has moved 3 of attributes from one "camp" to another. If idea was to separate attributes that affect mangling/type then we still have protection attributes. And with no plans to deprecate old syntax even more inconsistency had been introduced. 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. I don't see any _vision_ behind the change, just moving bits around. It is not well-thought.
Jan 28 2015
next sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, January 28, 2015 14:41:08 Dicebot via Digitalmars-d wrote:
 On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote:
 On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote:
 But in this case I see no improvement that could justify it.
Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388
Yes, but as it has been already mentioned in this thread new system is as much inconsistent - it simply has moved 3 of attributes from one "camp" to another. If idea was to separate attributes that affect mangling/type then we still have protection attributes. And with no plans to deprecate old syntax even more inconsistency had been introduced. 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. I don't see any _vision_ behind the change, just moving bits around. It is not well-thought.
Exactly. It's not like this is simply a discussion of whether a change which makes the language more consistent is worth the breaking changes that it causes. Rather, The change doesn't actually fix anything. It just moves stuff around. If more things were moved around, then maybe they'd become more consistent and would actually help the situation, but that's not what's happened. A few were attributes moved from one camp to the other with no real plan, and because it took attributes from the smaller camp and put them in the larger one, it's actually decreasing consistency and making the situation worse rather than improving it. If we're going to shuffle attributes around, we need to do it in a way that actually follows a plan and makes the language more consistent. That's not what's happening here. We either need to come up with a complete plan for shuffling attributes around in a way that will actually make them fully consistent, or we need to revert these changes and stick with the status quo. Anything else just shuffles things around without fixing the problem, and it increases confusion in the process. And honestly, after several discussions on this in the past, I don't think that it's actually possible to make the attributes fully 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 (e.g. on a whole bunch of keywords like private or final that other languages don't put on and which none of the current D literature or code out there puts on). I think that this is a case of folks trying to shuffle things around to fix something that just can't be fixed. At best, it'll just end up being ugly in a different way. - Jonathan M Davis
Jan 28 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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...
Jan 28 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Jan 28 2015
next sibling parent "Jonathan Marler" <johnnymarler gmail.com> writes:
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).
Jan 28 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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...
Jan 28 2015
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Jan 28 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jan 28 2015
prev sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
 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.
Jan 28 2015
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
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.
Jan 28 2015
prev sibling parent reply "Mike" <none none.com> writes:
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
Jan 28 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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.
Jan 28 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 28 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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.
Jan 28 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/15 10:37 AM, Jonathan Marler wrote:
 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.
That's not a misunderstanding. Your proposal has been understood. It can be made to work. That doesn't necessarily make it desirable. I don't think it's particularly helpful and Walter is against it, so simply put it won't happen. Let it go. Thanks for it and keep the good ideas coming. -- Andrei
Jan 28 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
 On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei 
 Alexandrescu wrote:
That's not a misunderstanding. Your proposal has been understood. It can be made to work. That doesn't necessarily make it desirable. I don't think it's particularly helpful and Walter is against it, so simply put it won't happen. Let it go. Thanks for it and keep the good ideas coming. -- Andrei
I don't have a problem with letting things go. What I have a problem with is poor communication. Walter never gave me a "valid" reason for why he didn't like the proposal. I'm totally ok if it gets rejected, but I have no idea why it was rejected. If anything, I just want to understand so that I make better decisions in the future. When I say he misunderstood I say that because the reason he gave for disliking the proposal doesn't make sense. He's using the "Straw Man" logical fallacy. He's attacking my proposal by assuming it's something that it isn't. He keeps mentioning keywords and "context-sensitive" tokens but my proposal has nothing to do with those things (even by his own definition of them). Quite frustrating. I hope you see that I'm just trying to understand. I don't care if I'm wrong, I just want someone to tell my why I'm wrong. And when someone asks me why we weren't able to make function attributes that weren't keywords, I can give them an answer.
Jan 28 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/15 10:59 AM, Jonathan Marler wrote:
 On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu
 wrote:
That's not a misunderstanding. Your proposal has been understood. It can be made to work. That doesn't necessarily make it desirable. I don't think it's particularly helpful and Walter is against it, so simply put it won't happen. Let it go. Thanks for it and keep the good ideas coming. -- Andrei
I don't have a problem with letting things go. What I have a problem with is poor communication. Walter never gave me a "valid" reason for why he didn't like the proposal. I'm totally ok if it gets rejected, but I have no idea why it was rejected. If anything, I just want to understand so that I make better decisions in the future. When I say he misunderstood I say that because the reason he gave for disliking the proposal doesn't make sense. He's using the "Straw Man" logical fallacy. He's attacking my proposal by assuming it's something that it isn't. He keeps mentioning keywords and "context-sensitive" tokens but my proposal has nothing to do with those things (even by his own definition of them). Quite frustrating. I hope you see that I'm just trying to understand. I don't care if I'm wrong, I just want someone to tell my why I'm wrong. And when someone asks me why we weren't able to make function attributes that weren't keywords, I can give them an answer.
It may be the case you're using different definitions of the term "contextual keyword". Far as I can tell you want the identifier "nogc" be recognized in certain places by the compiler as special, and otherwise just not be special at all. That's a contextual keyword. If that's the case you were well understood by both Walter and myself. I happen to recognize the merit of contextual keyword in general, but Walter has a stronger opposition to it. It doesn't seem to me this particular application is compelling enough to warrant the precedent. -- Andrei
Jan 28 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei 
Alexandrescu wrote:
 It may be the case you're using different definitions of the 
 term "contextual keyword". Far as I can tell you want the 
 identifier "nogc" be recognized in certain places by the 
 compiler as special, and otherwise just not be special at all. 
 That's a contextual keyword. If that's the case you were well 
 understood by both Walter and myself. I happen to recognize the 
 merit of contextual keyword in general, but Walter has a 
 stronger opposition to it. It doesn't seem to me this 
 particular application is compelling enough to warrant the 
 precedent. -- Andrei
Ok now we're getting somewhere. I guess the next thing I'd like to ask is what is the argument against having a word be a function attribute in one instance and a regular identifier in another? 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. Note: keep in mind...I'm not asking why it's bad to have a keyword (recognized as a keyword by the lexer) also be an identifier, I'm asking why it's bad to have a function attribute also be an identifier.
Jan 28 2015
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v 19:13 +0000:
 On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei 
 Alexandrescu wrote:
 It may be the case you're using different definitions of the 
 term "contextual keyword". Far as I can tell you want the 
 identifier "nogc" be recognized in certain places by the 
 compiler as special, and otherwise just not be special at all. 
 That's a contextual keyword. If that's the case you were well 
 understood by both Walter and myself. I happen to recognize the 
 merit of contextual keyword in general, but Walter has a 
 stronger opposition to it. It doesn't seem to me this 
 particular application is compelling enough to warrant the 
 precedent. -- Andrei
Ok now we're getting somewhere. I guess the next thing I'd like to ask is what is the argument against having a word be a function attribute in one instance and a regular identifier in another? 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.
Jan 28 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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
Jan 28 2015
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Jan 28 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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.
Jan 28 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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").
Jan 28 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright 
wrote:
 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.
That explains why new languages make ";" optional, or wait... Could it be that the language designers of new languages have realized that using ";" for discrimination on line endings is fragile and tedious. Could it be that new languages define grammars that are more robust than the one used by C? Like Go? Or to put it succinctly: If legibility is dependent on a little fly shit on the screen, then the language design sure isn't optimal.
Jan 28 2015
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 28 January 2015 at 22:44:45 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright 
 wrote:
 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.
That explains why new languages make ";" optional, or wait... Could it be that the language designers of new languages have realized that using ";" for discrimination on line endings is fragile and tedious. Could it be that new languages define grammars that are more robust than the one used by C? Like Go?
Counter example: Rust. Of course, Rust isn't the epitome of readability.
 Or to put it succinctly: If legibility is dependent on a little 
 fly shit on the screen, then the language design sure isn't 
 optimal.
Jan 29 2015
prev sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 28/01/2015 22:44, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 Could it be that new languages define grammars that are more robust than
 the one used by C? Like Go?
We're not going to significantly change the structural syntax of D, so it doesn't seem that your argument is particularly relevant here.
Jan 29 2015
prev sibling next sibling parent reply FG <home fgda.pl> writes:
On 2015-01-28 at 23:27, Walter Bright wrote:
 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.
I'm quite sure I have read this very same thing not so long ago. :)
Jan 28 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/15 3:14 PM, FG wrote:
 On 2015-01-28 at 23:27, Walter Bright wrote:
 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.
I'm quite sure I have read this very same thing not so long ago. :)
We should add that stuff and what Jonathan wrote to the FAQ on the wiki. -- Andrei
Jan 28 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/28/2015 3:14 PM, FG wrote:
 On 2015-01-28 at 23:27, Walter Bright wrote:
 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.
I'm quite sure I have read this very same thing not so long ago. :)
I repeat it regularly! It's one of those things that one only learns the hard way, because the subtleties of it are not at all obvious. It's one of the mistakes that inexperienced language designers make again and again. One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?)
Jan 28 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-29 01:19, Walter Bright wrote:

 One of the other mistakes they make is the great idea of implicit
 declaration of variables, and then ruefully have to deprecate/remove it
 a year or two later. (How could those experienced designers have missed
 this obviously great feature?!?)
Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. -- /Jacob Carlborg
Jan 29 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg
wrote:
 On 2015-01-29 01:19, Walter Bright wrote:

 One of the other mistakes they make is the great idea of 
 implicit
 declaration of variables, and then ruefully have to 
 deprecate/remove it
 a year or two later. (How could those experienced designers 
 have missed
 this obviously great feature?!?)
Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers.
And it is so bad when the codebase grows that people are willing to switch to Node.js (!)
Jan 29 2015
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 29 January 2015 at 17:17:44 UTC, deadalnix wrote:
 On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg
 wrote:
 On 2015-01-29 01:19, Walter Bright wrote:

 One of the other mistakes they make is the great idea of 
 implicit
 declaration of variables, and then ruefully have to 
 deprecate/remove it
 a year or two later. (How could those experienced designers 
 have missed
 this obviously great feature?!?)
Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers.
And it is so bad when the codebase grows that people are willing to switch to Node.js (!)
That is so yesterday, they are now either on Go or Clojure.
Jan 29 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-29 18:17, deadalnix wrote:

 And it is so bad when the codebase grows that people are willing
 to switch to Node.js (!)
And still people are using it successfully. -- /Jacob Carlborg
Jan 29 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 29 January 2015 at 19:49:58 UTC, Jacob Carlborg 
wrote:
 On 2015-01-29 18:17, deadalnix wrote:

 And it is so bad when the codebase grows that people are 
 willing
 to switch to Node.js (!)
And still people are using it successfully.
Yes, my point is that there is tradeof. This is easy to build something fast in ruby, but this becomes unmaintainable at scale. I'm not sure this is the tradeof we want in D.
Jan 29 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 29 Jan 2015 17:17:44 +0000, deadalnix wrote:

 On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote:
 On 2015-01-29 01:19, Walter Bright wrote:

 One of the other mistakes they make is the great idea of implicit
 declaration of variables, and then ruefully have to deprecate/remove
 it a year or two later. (How could those experienced designers have
 missed this obviously great feature?!?)
Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers.
=20 And it is so bad when the codebase grows that people are willing to switch to Node.js (!)
'cause they think that javascript is kind of magic that will turn their=20 shitcode to great code. what they didn't realise is that shitcode lives=20 in their heads, not in languages.=
Jan 29 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2015 6:00 AM, Jacob Carlborg wrote:
 On 2015-01-29 01:19, Walter Bright wrote:

 One of the other mistakes they make is the great idea of implicit
 declaration of variables, and then ruefully have to deprecate/remove it
 a year or two later. (How could those experienced designers have missed
 this obviously great feature?!?)
Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers.
"Some languages have started out with the implicit declaration behavior, but as they matured they provided an option to disable it (e.g. Perl's "use strict" or Visual Basic's "Option Explicit")." -- http://en.wikipedia.org/wiki/Declaration_(computer_programming)#Variables Ruby also has monkey patching, another misfeature. Even so, lots of languages survive execrable features if they are counterbalanced by more desirable one.
Jan 29 2015
next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thursday, January 29, 2015 13:47:47 Walter Bright via Digitalmars-d wrote:
 Even so, lots of languages survive execrable features if they are
 counterbalanced by more desirable one.
C! - Jonathan M Davis
Jan 29 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-29 22:47, Walter Bright wrote:

 Ruby also has monkey patching, another misfeature.
It works great, have you actually used it? The entire Rails plugin system is built around monkey patching. It's far more successful than any D project. -- /Jacob Carlborg
Jan 30 2015
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 30 January 2015 at 09:21:17 UTC, Jacob Carlborg wrote:
 On 2015-01-29 22:47, Walter Bright wrote:

 Ruby also has monkey patching, another misfeature.
It works great, have you actually used it? The entire Rails plugin system is built around monkey patching. It's far more successful than any D project.
I have to agree with Jacob. It's an extremely powerful tool. It's used for things that D would use templating, introspection, CTFE and mixins for. Of course, each of these has its disadvantages, but that doesn't make them misfeatures at all. Unlike real misfeatures, the chance that someone uses them (or monkey patching) by accident and unintentionally is low.
Jan 30 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-28 23:27, Walter Bright wrote:

 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.
A good language design that doesn't require the ; statement terminator would recognize "void func()" as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages. -- /Jacob Carlborg
Jan 29 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 29 January 2015 at 13:58:52 UTC, Jacob Carlborg 
wrote:
 A good language design that doesn't require the ; statement 
 terminator would recognize "void func()" as a valid statement 
 and implicit add ;. Scan the line, if a valid language 
 construct has been seen at the end of the line, insert a ;, if 
 not continue to the next line. That works in many languages.
Tells me what this function returns in javascript : function foo() { return { foo: "bar", } } Yes, you guessed right, it returns undefined. Ho you didn't ? What a surprise !
Jan 29 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 29 Jan 2015 14:58:51 +0100, Jacob Carlborg wrote:

 On 2015-01-28 23:27, Walter Bright wrote:
=20
 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 =3D 7;

 With your proposal, an error isn't discovered until the '=3D' is found.
=20 A good language design that doesn't require the ; statement terminator would recognize "void func()" as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages.
this never worked good. see deadalnix. or: foo.bar .zed is `.zed` a chained call or free call? oh, well, build symbol table to=20 find that? and what if we have free function `zed` and a method `zed`? there can be alot of such samples. implicit `;` never worked right in=20 grammars that allows arbitrary newlines. such grammars requires explicit=20 "end-of-sentence" signs to be parsable without ambiguities on almost each=20 code line.=
Jan 29 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-01-29 22:02, ketmar wrote:

 this never worked good. see deadalnix. or:

    foo.bar
      .zed
In Ruby ".zed" is not valid code, so in Ruby it means: foo.bar.zed; In D it, with my rules, it would mean: foo.bar; .zed; In D you would need to write: foo.bar. zed -- /Jacob Carlborg
Jan 30 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2015 5:58 AM, Jacob Carlborg wrote:
 On 2015-01-28 23:27, Walter Bright wrote:

 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.
A good language design that doesn't require the ; statement terminator would recognize "void func()" as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages.
Oh, I know it can be made to work. That wasn't my point, which I shall repeat: "error message clarity, recovery, and the correct identification of the location of the error degrades substantially" Notice that your comment is still relying on remaining redundancy to try to figure out where the ; is supposed to go.
Jan 29 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-29 22:50, Walter Bright wrote:

 "error message clarity, recovery, and the correct identification of the
 location of the error degrades substantially"
I never had problems with the error messages in Ruby. But I do have had problems with them in D. Example: int a = 3 int b = 4; The compiler will complain there's a missing semicolon on line 4 in front of "int". The user has most likely forget to add the semicolon at the end of the first line.
 Notice that your comment is still relying on remaining redundancy to try
 to figure out where the ; is supposed to go.
You need some kind of separation between the statements. In Ruby a newline works as a statement separator. -- /Jacob Carlborg
Jan 30 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 30 January 2015 at 09:27:09 UTC, Jacob Carlborg wrote:
 You need some kind of separation between the statements. In 
 Ruby a newline works as a statement separator.
I think Go actually injects ";" in the lexer on tokens that can end statements if the token is followed by newline. Sounds crazy, but it works for that grammar.
Jan 30 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/30/2015 1:27 AM, Jacob Carlborg wrote:
 In Ruby a newline works as a statement separator.
Making it not an example of what I was talking about.
Jan 30 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 28 January 2015 at 19:33:32 UTC, Jonathan Marler 
wrote:
 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.
Then I'm afraid the proposal is pointless :-( The goal AIUI is to make the language more consistent. If we can't use the new syntax everywhere (and later get rid of the old one), we can't achieve that.
Jan 29 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/15 11:13 AM, Jonathan Marler wrote:
 On Wednesday, 28 January 2015 at 19:04:50 UTC, Andrei Alexandrescu wrote:
 It may be the case you're using different definitions of the term
 "contextual keyword". Far as I can tell you want the identifier "nogc"
 be recognized in certain places by the compiler as special, and
 otherwise just not be special at all. That's a contextual keyword. If
 that's the case you were well understood by both Walter and myself. I
 happen to recognize the merit of contextual keyword in general, but
 Walter has a stronger opposition to it. It doesn't seem to me this
 particular application is compelling enough to warrant the precedent.
 -- Andrei
Ok now we're getting somewhere. I guess the next thing I'd like to ask is what is the argument against having a word be a function attribute in one instance and a regular identifier in another? 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. Note: keep in mind...I'm not asking why it's bad to have a keyword (recognized as a keyword by the lexer) also be an identifier, I'm asking why it's bad to have a function attribute also be an identifier.
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
Jan 28 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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!
Jan 28 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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!)
Jan 28 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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.
Jan 28 2015
prev sibling parent "Mike" <none none.com> writes:
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler 
wrote:

 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!
It would be nice to know the priorities of the leadership, but, if you have the skills to hack the compiler, bugzilla is the place to start earning one's wings and influence. I would love it you could fix this (these) bugs. https://issues.dlang.org/show_bug.cgi?id=13372 https://issues.dlang.org/show_bug.cgi?id=12496 And I'm sure bug fixes are already pre-approved. Mike
Jan 28 2015
prev sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Wednesday, 28 January 2015 at 18:37:48 UTC, Jonathan Marler 
wrote:
 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.
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.
Jan 28 2015
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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; The first appearance is a type and the second is an identifier. I'm sure there are many examples of this in the language. Anyway, I disagree with your conclusion, however, I agree that this could be a concern.
Jan 28 2015
next sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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.
Jan 28 2015
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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 ?
Jan 28 2015
prev sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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.
Jan 28 2015
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Jan 28 2015
parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim 
Grøstad wrote:
 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.
Lol, you guys are hilarious. There's D1, D2 and now DOla and DKetmar!
Jan 28 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 28 Jan 2015 22:39:01 +0000, Jonathan Marler wrote:

 On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim Gr=C3=B8stad
 wrote:
 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.
=20 Lol, you guys are hilarious. There's D1, D2 and now DOla and DKetmar!
not "DKetmar", it's titled "Aliced". ;-)=
Jan 28 2015
prev sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler 
wrote:
 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.
I invested the time because you took a very polite and civil tone. ;) I'm glad I was able to find a way of wording it that helped. I'm also glad Walter was able to follow it up with an even better reasoning which speaks from deep experience, which I could not have done. Let's move on!
Jan 28 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 29 January 2015 at 03:14:10 UTC, Zach the Mystic 
wrote:
 helped. I'm also glad Walter was able to follow it up with an 
 even better reasoning which speaks from deep experience, which 
 I could not have done. Let's move on!
Indeed, Walter has some deep reasoning ENTIRELY based on personal experience. Unfortunately it totally lacks theoretical backing and shows a complete disregard for how usability evaluation is done. Other popular languages, who have users that do not complain about language syntax, are obviously wrong because they eschew Walter's personal deep reasoned experience. These users must be delusional and clueless for being happy with a syntax that is obviously flawed for not providing redundant noise that improves usability! While D, who have few users of which a fair share keep complaining about the syntax, is beyond critique with an ever expanding feature set and an increasing pile of reserved words that prevent library authors from implementing the most common standard on this planet. Here is the crux: nobody forces people who don't want to use "body" as an identifier to use it, but that is not a good argument for preventing everybody else from using it as an identifier! D is a practically impractical language until it provides: 1. feature freeze 2. semantic specification 3. clean slate syntax upgrade D is a hobby language and is loosing more talent than it should for not following a reasonable trajectory. 16 years in the making, still no stable release.
Jan 29 2015
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 29 January 2015 at 10:22:13 UTC, Ola Fosheim Grøstad 
wrote:
 Indeed, Walter has some deep reasoning ENTIRELY based on 
 personal experience. Unfortunately it totally lacks theoretical 
 backing and shows a complete disregard for how usability 
 evaluation is done.

 Other popular languages, who have users that do not complain 
 about language syntax, are obviously wrong because they eschew 
 Walter's personal deep reasoned experience. These users must be 
 delusional and clueless for being happy with a syntax that is 
 obviously flawed for not providing redundant noise that 
 improves usability!

 While D, who have few users of which a fair share keep 
 complaining about the syntax, is beyond critique with an ever 
 expanding feature set and an increasing pile of reserved words 
 that prevent library authors from implementing the most common 
 standard on this planet.

 Here is the crux: nobody forces people who don't want to use 
 "body" as an identifier to use it, but that is not a good 
 argument for preventing everybody else from using it as an 
 identifier!

 D is a practically impractical language until it provides:

 1. feature freeze

 2. semantic specification

 3. clean slate syntax upgrade

 D is a hobby language and is loosing more talent than it should 
 for not following a reasonable trajectory.

 16 years in the making, still no stable release.
In the Mythical Man Month, Brooks advises for a single person responsible for architecture, or a dynamic duo (this is exactly what we are with Walter and Andrei). This role was rediscovered as "product owner" in Agile settings. Strong leadership and saying "no" more often that people would like is a constant among good projects. I also made D proposals back in the days and they were crap proposals (literally). You, personally, want syntax changes AND feature freeze. Nobody would use a language whose leaders have said yes to the ideas of the every abusive internet users out there.
Jan 29 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 29 January 2015 at 10:50:49 UTC, ponce wrote:
 In the Mythical Man Month, Brooks advises for a single person 
 responsible for architecture, or a dynamic duo (this is exactly 
 what we are with Walter and Andrei).
You mean like Batman? I don't feel like discussing system development principles with you if you think the "dynamic duo" is anywhere near following sound software engineering principles. It is not a fun topic to teach (yes, I have done that).
 This role was rediscovered as "product owner" in Agile settings.
 Strong leadership and saying "no" more often that people would 
 like is a constant among good projects.
The only thing that truly matters is that you have a plan and a reasonable process to back it up. Leadership is about facilitating the process. A role is not a person, it is backing a task that to be fulfilled to facilitate the process in a predictable and orderly fashion.
 I also made D proposals back in the days and they were  crap 
 proposals (literally). You, personally, want syntax changes AND 
 feature freeze.
I personally don't think it is reasonable for Walter and Andrei to present D as a tool that is suitable for production. If it is, then they have to fess up to massive critique. Take a look at dlang.org, where does it say "experimental language"? It used to say "beta", which actually should have been "alpha"... I personally only want D to follow sound engineering principles. I personally don't want syntax changes or feature freeze, since it won't help without a solid process to back it up.
 Nobody would use a language whose leaders have said yes to the 
 ideas of the every abusive internet users out there.
I think it is abusive and dishonest to present a language as ready for use when it nowhere near a stable release. I've previously requested that they actually do language design by writing up a spec for where D is heading, so that people can make up their mind and decide to provide "implementation power" if they like the presented outcome. Without a clear horizon, it makes no sense to participate unless you have it as a hobby. That slows down progress. That is what makes Rust and Go winners and D a stagnation. What I suggest is the best for D is: 1. Feature freeze. 2. Fix semantics/refactor compiler internals. 3. Fix syntax to be mainstream friendly. In that order. I have no hope that it will happen without a major restructuring of the process. I'm totally with ketmar on that front.
Jan 29 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-01-28 20:07, Jonathan Marler wrote:

 You seem to be defining a keyword in terms of an identifier that
 is recognized by the compiler to have a special  meaning.
By that definition basically all declarations in the object module is a keyword :) -- /Jacob Carlborg
Jan 29 2015
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
That's a reserved word. A reserved word cannot be used as an identifier. A keyword is a phrase that has a special semantic meaning in a context. That does not make it context sensitive if the language can be recognized by a context free grammar... Confusing? I guess... Some languages would allow this: "if if = 0 then ... fi", it is not context sensitive because it can be recognized by a CFG. The first "if" is a keyword. The second "if" is an identifier.
Jan 28 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 28 Jan 2015 18:54:27 +0000, 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.
yep. that is "slave to the machine" approach. i don't really care how=20 hard machine should work to understand what i want. ;-) i.e. i can't see why i have to deal with problems of compiler/tool/editor=20 author. it's easy -- at least in this case -- for human to see where=20 keywords are keywords. machine can see that too with some analysis. yet=20 somehow situation is horribly reversed: instead of machine helping me to=20 do what i want, that's me who must obey the machine orders and do the=20 work that machine can do for me.=
Jan 28 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
 On Wed, 28 Jan 2015 18:54:27 +0000, 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.
yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-) i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me.
That is a retarded mindset. It is not about how hard it is for the machine, but for tool writer. I know many people look down on java, but quite frankly, the tooling is just way better than pretty much anything else. One could argue this is because of corporate support, but other languages like C++ also have important corporate support. And still, C++ tooling mostly suck. Honestly, pretty anything except The problem of the tool writer is your problem, because any tool that isn't written is work you need to yourself. And then who's the slave to the machine ?
Jan 28 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wed, 28 Jan 2015 23:36:29 +0000, deadalnix wrote:

 On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
 On Wed, 28 Jan 2015 18:54:27 +0000, 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.
yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-) i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me.
=20 That is a retarded mindset. It is not about how hard it is for the machine, but for tool writer. =20 I know many people look down on java, but quite frankly, the tooling is just way better than pretty much anything else. One could argue this is because of corporate support, but other languages like C++ also have important corporate support. And still, C++ tooling mostly suck. =20 The problem of the tool writer is your problem, because any tool that isn't written is work you need to yourself. And then who's the slave to the machine ?
and there are at least 4 available codebases for writing tools. for C++=20 there is DMD frontend. for D there is dscanner, magicport and SDC. yet=20 instead of thinking how all that code can help me and made my life=20 better, i should think how making my life harder will help to write great=20 tools somewhere in the future. that is what i call "retarded mindset".=
Jan 28 2015
prev sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
 On Wed, 28 Jan 2015 18:54:27 +0000, 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.
yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-)
I take it you also don't care if your IDE lags for 5 seconds every time you type a character?
 i.e. i can't see why i have to deal with problems of 
 compiler/tool/editor
 author. it's easy -- at least in this case -- for human to see 
 where
 keywords are keywords. machine can see that too with some 
 analysis.
I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem. You know what else is easy for humans? Image and audio processing and knowing how to walk. Things that are easy for machines are hard for humans. Things that are easy for humans are hard for machines.
 yet somehow situation is horribly reversed: instead of machine 
 helping me to
 do what i want, that's me who must obey the machine orders and 
 do the
 work that machine can do for me.
If it really is work that the machine can do for you, why haven't you made the machine do it?
Jan 28 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 29 Jan 2015 00:03:51 +0000, Brian Schott wrote:

 On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
 On Wed, 28 Jan 2015 18:54:27 +0000, 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.
yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-)
=20 I take it you also don't care if your IDE lags for 5 seconds every time you type a character?
sure, i will not use such IDE, 'cause it's fubared. yet it has nothing=20 with "great grammars": it's fubared 'cause the authors were thinking=20 about "how we can write that cool IDE so everybody will prise us" instead=20 of "how we can write our IDE that it will be fast and easy". and generally speaking, IDEs sux.
 i.e. i can't see why i have to deal with problems of
 compiler/tool/editor author. it's easy -- at least in this case -- for
 human to see where keywords are keywords. machine can see that too with
 some analysis.
=20 I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem.
that's good. as we already have at least 4 codebases to build tools upon,=20 and you gave up using that and insisting on writing another one, and=20 failed... i doubt that your tool was really important or even usable. so=20 now i don't have to try another tool just to throw it away.
 You know what else is easy for humans? Image and audio processing and
 knowing how to walk. Things that are easy for machines are hard for
 humans. Things that are easy for humans are hard for machines.
i wonder why we don't do all our programs in machine code today. 'cause,=20 you know, it's hard for machine to parse all that languages. so let's use=20 machine code!
 yet somehow situation is horribly reversed: instead of machine helping
 me to do what i want, that's me who must obey the machine orders and do
 the work that machine can do for me.
=20 If it really is work that the machine can do for you, why haven't you made the machine do it?
i did. i'm not using "vanilla" D, that was mentioned in this thread. and=20 you know what? i didn't encounter *any* problems with it.=
Jan 28 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote:
 that's good. as we already have at least 4 codebases to build 
 tools upon,
 and you gave up using that and insisting on writing another 
 one, and
 failed... i doubt that your tool was really important or even 
 usable. so
 now i don't have to try another tool just to throw it away.
That's exactly right. I gave up on using dscanner and insisted on writing dscanner instead.
Jan 28 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 29 Jan 2015 00:29:26 +0000, Brian Schott wrote:

 On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote:
 that's good. as we already have at least 4 codebases to build tools
 upon,
 and you gave up using that and insisting on writing another one, and
 failed... i doubt that your tool was really important or even usable.
 so now i don't have to try another tool just to throw it away.
=20 That's exactly right. I gave up on using dscanner and insisted on writing dscanner instead.
sorry, it wasn't obvious that i was talking not about you in personal, as=20 i read your text as a text about "jack the random, tool writer".=
Jan 28 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/15 4:29 PM, Brian Schott wrote:
 I gave up on using dscanner and insisted on writing dscanner instead.
Nice. Interrogative - time to promote dscanner to tools/? Brian, what do you think? -- Andrei
Jan 28 2015
parent "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 29 January 2015 at 02:23:56 UTC, Andrei Alexandrescu 
wrote:
 Nice. Interrogative - time to promote dscanner to tools/? 
 Brian, what do you think? -- Andrei
That discussion probably deserves its own thread.
Jan 28 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote:
 On Thu, 29 Jan 2015 00:03:51 +0000, Brian Schott wrote:

 On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote:
 On Wed, 28 Jan 2015 18:54:27 +0000, 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.
yep. that is "slave to the machine" approach. i don't really care how hard machine should work to understand what i want. ;-)
I take it you also don't care if your IDE lags for 5 seconds every time you type a character?
sure, i will not use such IDE, 'cause it's fubared. yet it has nothing with "great grammars": it's fubared 'cause the authors were thinking about "how we can write that cool IDE so everybody will prise us" instead of "how we can write our IDE that it will be fast and easy".
why bother when vim exists : )
 i.e. i can't see why i have to deal with problems of
 compiler/tool/editor author. it's easy -- at least in this 
 case -- for
 human to see where keywords are keywords. machine can see 
 that too with
 some analysis.
I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem.
that's good. as we already have at least 4 codebases to build tools upon, and you gave up using that and insisting on writing another one, and failed... i doubt that your tool was really important or even usable. so now i don't have to try another tool just to throw it away.
Uncalled for IMO, Schott's tools are great.
Jan 28 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 29 Jan 2015 00:33:39 +0000, weaselcat wrote:

 Uncalled for IMO, Schott's tools are great.
sure. i wasn't talking about Brian in my text, that was my dumbiness that=20 paints the text personal.=
Jan 28 2015
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 29 January 2015 at 00:03:52 UTC, Brian Schott wrote:
 I take it you also don't care if your IDE lags for 5 seconds 
 every time you type a character?
Actually, modern parsers can parse ambiguous grammars in O(N) using memoing. Just because you are reluctant to implement a modern parser does not mean that it cannot be done and wrapped up as a library.
 I'm a tool writer. If I have enough problems, I don't build the 
 tool. The problem is now your problem.
D does not even have a published grammar that rejects programs that are not well formed. The problem is not that having a programmer friendly will cause tool writer problems. The problem is in D specification and semantics which are C++ish. What people have requested is not C++ish it is well within a CFG.
 You know what else is easy for humans? Image and audio 
 processing and knowing how to walk. Things that are easy for 
 machines are hard for humans. Things that are easy for humans 
 are hard for machines.
What is easy for a standards committee is to check that their and SQL. Not being able to repesent those in D will make D less attractive. Besides there is no ambiguity in allowing arbitrary field names since they are preceded by a ".". (nobody cares about local variables)
Jan 29 2015
prev sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
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
Jan 28 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 28 January 2015 at 14:41:09 UTC, Dicebot wrote:
 And with no plans to deprecate old syntax even more 
 inconsistency had been introduced.
When the problem arises, then.
 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?
 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.
Jan 28 2015
parent reply "Dicebot" <public dicebot.lv> writes:
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.
Jan 28 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 28 2015
parent reply "Dicebot" <public dicebot.lv> writes:
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 :)
Jan 28 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 28 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 28 January 2015 at 15:25:05 UTC, Dicebot wrote:
 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 suppose, when UDA conflicts with builtin attribute, that UDA can be still disambiguated through module system.
Jan 29 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-01-29 16:29, Kagamin wrote:

 I suppose, when UDA conflicts with builtin attribute, that UDA can be
 still disambiguated through module system.
We can always add another sign in front of new attributes ;) -- /Jacob Carlborg
Jan 29 2015
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 28 January 2015 at 13:14:16 UTC, bearophile wrote:
 The word "obvious" is important, because usually there are 
 multiple ways to do something, but only one of them should be 
 obvious in Python :-)
Yes... but which one is obvious: [0.1*x for x in range(10)] map(operator.mul,range(10),[0.1]*10) numpy.arange(0.,0.95,0.1) numpy.linspace(0,0.9,num=10) list(itertools.islice(itertools.count(0.0, 0.1), 10)) ...
Jan 28 2015
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ola Fosheim Grøstad:

 [0.1*x for x in range(10)]

 map(operator.mul,range(10),[0.1]*10)

 numpy.arange(0.,0.95,0.1)

 numpy.linspace(0,0.9,num=10)

 list(itertools.islice(itertools.count(0.0, 0.1), 10))
The first one (the list comp) is Pythonic, and it's obviously the obvious one :-) If you want/need to use numpy, the fourth is good. No problems :-) Bye, bearophile
Jan 28 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 28 January 2015 at 13:58:22 UTC, bearophile wrote:
 The first one (the list comp) is Pythonic, and it's obviously 
 the obvious one :-)

 If you want/need to use numpy, the fourth is good.

 No problems :-)
Ok, so we agree, but I think the obvious way if we forget about languages would be to combine range with element wise multiplication, e.g. "range(10) .* 0.1". Good usability often means... stick to common conventions, but be internally consistent. Most language designs fail here by not caring enough for the know-how users bring to the table... :-/
Jan 28 2015
prev sibling parent zeljkog <zeljkog home.com> writes:
On 28.01.15 14:14, bearophile wrote:
 Dicebot:

 Yes, but it didn't also fix anything, only introduced more ways to do
 the same thing - without any plans for some consistent model.
One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it.
Yes but also: Practicality beats purity :)
Jan 28 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/28/15 4:11 AM, Dicebot wrote:
 On Tuesday, 27 January 2015 at 10:50:53 UTC, Walter Bright wrote:
 This change didn't break a single line in the libraries or the test
 suite.
Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. It is simply moving things around for the sake of marking some bugzilla report as closed - there is no consistent rationale for applying to attributes available. Just the fact that change can't possibly break anything doesn't mean it is can't have negative value. It _may_ have some well-though rationale behind I am failing to spot but that is not presented to users in any way.
Change has been reverted. -- Andrei
Jan 28 2015
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 28 January 2015 at 14:59:48 UTC, Andrei 
Alexandrescu wrote:
 Change has been reverted. -- Andrei
Thank you very much. Just to be perfectly clear : I am not against consolidating attributes or even breaking things. Only thing I want is for such changes to be done _simultaneously_ with some more detailed rationale which can be linked from a changelog and would explain everyone outside of this NG what the change is about. It is quite likely that trying to write such rationale will highlight more internal inconsistencies than any discussion could.
Jan 28 2015
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wednesday, January 28, 2015 06:59:49 Andrei Alexandrescu via Digitalmars-d
wrote:
 Change has been reverted. -- Andrei
Yay! - Jonathan M Davis
Jan 28 2015
prev sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 26/01/15 22:29, Dicebot via Digitalmars-d wrote:
 However my complaint is not about the change itself (though I personally
 disagree with Don reasoning in that issue, it is a delicate matter) but about
 the fact that it is again done as a casual PR and our breaking change culture
 does not seem to change : it is still all or nothing approach. No automatic
 migration tools, no easily found rationale / explanation, no posts in
D.announce
 - just an ordinary commit. No wonder any of more notable change is considered
 that scary.
I don't have any disagreement with your request for better reporting and public justification of decisions like this, but I don't understand why you consider it a breaking change. It's not backwards-incompatible -- the existing pure and nothrow will still work (which I just verified by building druntime and phobos with a dmd instance built from the controversial commit). BTW what is return meant to achieve? I realize I'm not familiar with this attribute.
Jan 28 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 28 January 2015 at 22:58:02 UTC, Joseph Rushton 
Wakeling wrote:
 On 26/01/15 22:29, Dicebot via Digitalmars-d wrote:
 However my complaint is not about the change itself (though I 
 personally
 disagree with Don reasoning in that issue, it is a delicate 
 matter) but about
 the fact that it is again done as a casual PR and our breaking 
 change culture
 does not seem to change : it is still all or nothing approach. 
 No automatic
 migration tools, no easily found rationale / explanation, no 
 posts in D.announce
 - just an ordinary commit. No wonder any of more notable 
 change is considered
 that scary.
I don't have any disagreement with your request for better reporting and public justification of decisions like this, but I don't understand why you consider it a breaking change. It's not backwards-incompatible -- the existing pure and nothrow will still work (which I just verified by building druntime and phobos with a dmd instance built from the controversial commit).
I haven't said it is a breaking change on its own - but that doesn't mean it is any considerably better migration-wise.
 BTW what is  return meant to achieve?  I realize I'm not 
 familiar with this attribute.
http://wiki.dlang.org/DIP25
Jan 28 2015
parent Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 29/01/15 00:06, Dicebot via Digitalmars-d wrote:
 I haven't said it is a breaking change on its own - but that doesn't mean it is
 any considerably better migration-wise.
Yea, you're right, this isn't about whether the feature is good or not (personally, I find Don's case for it persuasive) -- it's about having a well-signposted procedure for changing the language.
 BTW what is  return meant to achieve?  I realize I'm not familiar with this
 attribute.
http://wiki.dlang.org/DIP25
Oh, of course. Though it feels a bit weird, the possibility to write, safe ref int identity( return ref int x) { return x; }
Jan 28 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 26 January 2015 at 20:26:02 UTC, Dicebot wrote:
 It was sad that calls for more breakage were mostly ignored. 
 But there is one thing now that is even worse - referring to 
 #pleasebreakmycode as an excuse to introduce random changes 
 based on random reddit comment - and completely dismissing 
 everything that was said on topic initially. Resulting in 
 exactly the opposite action that was asked to.

 Please, revert this PR asap. After that it can possibly be 
 introduced after meeting necessary prerequisites:

 1) explanation of problem it fixes
 2) design rationale for new model
 3) evaluation of ROI
 4) tools for simple migration - either as part of dfix or 
 compiler

 This is absolutely mandatory list for any change of language 
 fundamentals to be considered legitimate.
+1, and I doubt the ROI analysis will come positive.
Jan 26 2015
prev sibling next sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:
 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.
For my part, a 'dfix' solution is worth it. Anything else, not.
Jan 26 2015
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Previously, it's all been advocacy and "break my code"
Breaking the code should be justified by a worth gain. This patch is of negative value. Bye, bearophile
Jan 26 2015
parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 26/01/2015 21:20, bearophile wrote:
 Walter Bright:

 Previously, it's all been advocacy and "break my code"
Breaking the code should be justified by a worth gain. This patch is of negative value.
It doesn't break code.
Jan 27 2015
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright 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.
Yes, please! (at least about the "break my code" part)
 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.
Not a deal-breaker for me, but I agree with the sentiment, and I think it makes for a more professional language if such inconsistencies are addressed.
 Frankly, I think that is a great bikeshedding non-issue that 
 distracts us from what is important.
Yes, there is no correlation between what's important, and what people choose to work on, because there is no consensus on what's important, and if there is it's usually beyond the ability of most contributors, so it doesn't get worked on anyway. Personally, I find small changes like this welcome because they make for a more polished experience.
 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.
A dangerous precedent. I suspect the push-back against this change has probably ruined any chance of further polishing the language. From: https://issues.dlang.org/show_bug.cgi?id=13388#c27 ***
 I really think that we've passed the point where it's worth 
 fixing it.
NO!!!! This attitude is the biggest problem D has. Please, watch Scott Meyer's talk again. "Most D code is yet to be written". The future benefits of fixing this kind of crap, are huge. *** In fact, it is the attitude against change that has put me on the fence about D, when I was quite an advocate about a year ago. It has also made me reluctant to put forth the necessary effort to study and make any significant contributions because the controversy, as exhibited here, would likely erase my entire investment. Instead, I have begun exploring other options while keeping one foot on the raft. I agree that, in general, D should take a more disciplined approach to development, but keep in mind that if contributors have to go through too much controversy and bureaucracy we're not going to see much change (perhaps that's what some want). I feel for Walter. He's damned if he does and damned if he doesn't. Somehow, this herd of cats need to figure out where it wants to go, and I need to figure out whether to go all in or jump ship. Mike
Jan 26 2015
next sibling parent reply "uri" <uri.grill gmail.com> writes:
On Tuesday, 27 January 2015 at 01:32:23 UTC, Mike wrote:
 On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright 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.
Yes, please! (at least about the "break my code" part)
 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.
Not a deal-breaker for me, but I agree with the sentiment, and I think it makes for a more professional language if such inconsistencies are addressed.
 Frankly, I think that is a great bikeshedding non-issue that 
 distracts us from what is important.
Yes, there is no correlation between what's important, and what people choose to work on, because there is no consensus on what's important, and if there is it's usually beyond the ability of most contributors, so it doesn't get worked on anyway. Personally, I find small changes like this welcome because they make for a more polished experience.
 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.
A dangerous precedent. I suspect the push-back against this change has probably ruined any chance of further polishing the language. From: https://issues.dlang.org/show_bug.cgi?id=13388#c27 ***
 I really think that we've passed the point where it's worth 
 fixing it.
NO!!!! This attitude is the biggest problem D has. Please, watch Scott Meyer's talk again. "Most D code is yet to be written". The future benefits of fixing this kind of crap, are huge. *** In fact, it is the attitude against change that has put me on the fence about D, when I was quite an advocate about a year ago. It has also made me reluctant to put forth the necessary effort to study and make any significant contributions because the controversy, as exhibited here, would likely erase my entire investment. Instead, I have begun exploring other options while keeping one foot on the raft. I agree that, in general, D should take a more disciplined approach to development, but keep in mind that if contributors have to go through too much controversy and bureaucracy we're not going to see much change (perhaps that's what some want). I feel for Walter. He's damned if he does and damned if he doesn't. Somehow, this herd of cats need to figure out where it wants to go, and I need to figure out whether to go all in or jump ship. Mike
+1 to all of this as it mirrors exactly how I feel about D at this point in time. 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. Cheers, uri
Jan 26 2015
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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?
Jan 26 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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."
Jan 26 2015
next sibling parent reply "Jonathan Marler" <johnnymarler gmail.com> writes:
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.
Jan 26 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
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.
Jan 26 2015
next sibling parent "Jonathan Marler" <johnnymarler gmail.com> writes:
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?)
Jan 26 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-27 04:54, Zach the Mystic wrote:

 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.
Seems overly complicated. How about the compiler just outputs new files instead. -- /Jacob Carlborg
Jan 27 2015
parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Tuesday, 27 January 2015 at 10:37:37 UTC, Jacob Carlborg wrote:
 Seems overly complicated. How about the compiler just outputs 
 new files instead.
The thing I care about is that the compiler leaves the user with no doubt as to what he should do next and how to automatically fix his programs. The actual method of doing this is trivial by comparison.
Jan 27 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/15 7:25 PM, 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."
I'm ready to commit to dfix. Problem is many of the changes suggested are unlikely to mark much improvement, while miring us in the perpetual illusion of making progress. The fact that we can avail ourselves of a tactical tool that makes changes easy is helpful but also opens opportunity of abuse. Let's stop shuffling the deck. I mean it. Stop shuffling the freaking deck. Fix the real issues in the language. Add new libraries. Be original. Be creative. Do real work. Thanks, Andrei
Jan 26 2015
next sibling parent "uri" <uri.grill gmail.com> writes:
On Tuesday, 27 January 2015 at 04:10:24 UTC, Andrei Alexandrescu 
wrote:
 On 1/26/15 7:25 PM, 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."
I'm ready to commit to dfix. Problem is many of the changes suggested are unlikely to mark much improvement, while miring us in the perpetual illusion of making progress. The fact that we can avail ourselves of a tactical tool that makes changes easy is helpful but also opens opportunity of abuse. Let's stop shuffling the deck. I mean it. Stop shuffling the freaking deck. Fix the real issues in the language. Add new libraries. Be original. Be creative. Do real work. Thanks, Andrei
Well said. I've been wavering for a few months between D and Python for teams on smaller internal projects. IMO this is the right attitude from core D devs to finish off D2. Cheers, uri
Jan 26 2015
prev sibling parent "Zach the Mystic" <reachzach gggmail.com> writes:
On Tuesday, 27 January 2015 at 04:10:24 UTC, Andrei Alexandrescu 
wrote:
 I'm ready to commit to dfix. Problem is many of the changes 
 suggested are unlikely to mark much improvement, while miring 
 us in the perpetual illusion of making progress.
I don't think there's any illusion about D's great progress. D really has been making incredible progress. But also, don't you think it's progress to really solve issues, even little ones, such that threads like this never take place again? The way I see it, it's either dfix or the status quo for this issue. The current pull request is not decisive enough. So I talk about dfix, because it seems like the right tool for the job. Yes, it's tantalizing to imagine what other uses it has, but we won't know until it's in the tool belt and available to use. Maybe it'll have no other uses. Maybe all other potential uses will be "illusions of progress". But to me, it's attractive. It offers the best odds at really closing the case on a lot of nitpicks people have about D right now.
 The fact that we can avail ourselves of a tactical tool that 
 makes changes easy is helpful but also opens opportunity of 
 abuse.
What I hear you say is that you may not want the added responsibility of yours and Walter's making decisions on all the new possibilities it opens up. And maybe you're right about that. All I can do is make arguments, while you two have to decide Yes, or No. I want my arguments to help make your decisions easier. That's my goal. But I won't deny that (to use a tired cliche that actually makes sense here) with added power comes added responsibility.
 Let's stop shuffling the deck. I mean it. Stop shuffling the 
 freaking deck. Fix the real issues in the language. Add new 
 libraries. Be original. Be creative. Do real work.
How is the pull request which started this post not shuffling the deck? If it's not an issue, why make a pull request to begin with? Also, I hope it helps to realize that not everyone is qualified to give valuable feedback on some of the larger issues D faces. I definitely feel out of my league on many topics here, notwithstanding the crazy ideas that just pop into my head sometimes. :-/ But simply allowing people to chatter about the issues they do feel competent to discuss can have a very positive effect on the community. I don't think it stops you or anyone else from starting threads on the bigger animals in the arena. Not everyone's playing with the same set of marbles here. But I'll admit I don't know exactly how you feel. Just focus on what you care about and be honest about what you currently consider worthy and not worthy of your very valuable time. Destroy! :-)
Jan 26 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/15 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.
Fiddling with " " is not important. -- Andrei
Jan 26 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 26 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 7:58 PM, Andrei Alexandrescu wrote:
 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
I agree. Let's not get mired in an "illusion of progress".
Jan 26 2015
prev sibling parent reply "Mike" <none none.com> writes:
On Tuesday, 27 January 2015 at 03:58:34 UTC, Andrei Alexandrescu 
wrote:
 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.
Agreed, but... It is not the case that trivial matters like this are taking resources away from somewhere else. Take away all the trivia, and the important stuff still wouldn't get done because each cat in this herd disagrees on where to go or how to get there. IMO, none of these light bulbs are blocking the sun, and at least they are making some contribution to the ambient light. Mike
Jan 26 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/15 10:32 PM, Mike wrote:
 On Tuesday, 27 January 2015 at 03:58:34 UTC, Andrei Alexandrescu wrote:
 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.
Agreed, but... It is not the case that trivial matters like this are taking resources away from somewhere else.
I think they are. No reply needed. Andrei
Jan 26 2015
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 01:32:21 +0000, Mike wrote:

 In fact, it is the attitude against change that has put me on the fence
 about D, when I was quite an advocate about a year ago.  It has also
 made me reluctant to put forth the necessary effort to study and make
 any significant contributions because the controversy, as exhibited
 here, would likely erase my entire investment.  Instead, I have begun
 exploring other options while keeping one foot on the raft.
heh. i was very passionate about D, and i started the process of=20 migration of all our work projects (i'm a head of software company with=20 ~100 employees, if anybody is interested) to D. but then i realised that=20 D -- being a best programming language i've seen in my life -- is a toy=20 project. just think about it as a personal toy. and then you'll know what=20 expect from it.=
Jan 27 2015
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:
 heh. i was very passionate about D, and i started the process of
 migration of all our work projects (i'm a head of software 
 company with
 ~100 employees, if anybody is interested) to D. but then i 
 realised that
 D -- being a best programming language i've seen in my life -- 
 is a toy
 project. just think about it as a personal toy. and then you'll 
 know what
 expect from it.
A head of a 1000 employee software company would certainly have the power to change that rather than spending his time complaining on a NG.
Jan 27 2015
next sibling parent "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Tuesday, 27 January 2015 at 08:44:19 UTC, deadalnix wrote:
 On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:
 heh. i was very passionate about D, and i started the process 
 of
 migration of all our work projects (i'm a head of software 
 company with
 ~100 employees, if anybody is interested) to D. but then i 
 realised that
 D -- being a best programming language i've seen in my life -- 
 is a toy
 project. just think about it as a personal toy. and then 
 you'll know what
 expect from it.
A head of a 1000 employee software company would certainly have the power to change that rather than spending his time complaining on a NG.
If I have interpreted this post in the correct way, this is a very unfair comment, deadline. --- Paolo
Jan 27 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 08:44:17 +0000, deadalnix wrote:

 On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:
 heh. i was very passionate about D, and i started the process of
 migration of all our work projects (i'm a head of software company with
 ~100 employees, if anybody is interested) to D. but then i realised
 that D -- being a best programming language i've seen in my life -- is
 a toy project. just think about it as a personal toy. and then you'll
 know what expect from it.
=20 A head of a 1000 employee software company would certainly have the power to change that rather than spending his time complaining on a NG.
i don't know where you found that "1000" number, i was talking about=20 "100". it's a very different thing. and then: do you proposing a fork? sure, i can do that. actually, i'm=20 using a very different D already (heh, people that are interested in my=20 public code -- noone, actually -- may notice that all my modules are=20 "aliced" now; that's 'cause i want them to fail early instead of being=20 asked why they errored in the middle). but will it be good for D? i'm not=20 making my fork public for a reason. and i'm writing here for a reason=20 too. did you notice that almost all of my topics (not that many,=20 actually) got a lenghty discussion? isn't that a sign that i'm talking=20 about important things?=
Jan 27 2015
prev sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:
 On Tue, 27 Jan 2015 01:32:21 +0000, Mike wrote:

  i started the process of migration of all our work projects 
 (i'm a head of software company with ~100 employees, if anybody 
 is interested) to D. but then i realised that D -- being a best 
 programming language i've seen in my life -- is a toy project. 
 just think about it as a personal toy. and then you'll know 
 what expect from it.
I'm interested! I'm interested! ;-P Our jobs are similar: we have to scout out new technologies for our companies, and, with an hand on the hearth and fingers crossed, we have to judge the risks/benefits about spending money and time on them. It's not an easy job in my opinion, expecially nowadays with all that trees in the forest... I strongly believe in D, and we have migrated all our major projects over it, but sometimes, when I'm alone with my thoughts, I not sure if the "force is strong in me" like at the beginning... Well, we'll see: alea iacta est. --- Paolo
Jan 27 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 08:47:43 +0000, Paolo Invernizzi wrote:

 On Tuesday, 27 January 2015 at 08:07:11 UTC, ketmar wrote:
 On Tue, 27 Jan 2015 01:32:21 +0000, Mike wrote:

  i started the process of migration of all our work projects
 (i'm a head of software company with ~100 employees, if anybody is
 interested) to D. but then i realised that D -- being a best
 programming language i've seen in my life -- is a toy project. just
 think about it as a personal toy. and then you'll know what expect from
 it.
=20 I'm interested! I'm interested! ;-P =20 Our jobs are similar: we have to scout out new technologies for our companies, and, with an hand on the hearth and fingers crossed, we have to judge the risks/benefits about spending money and time on them. =20 It's not an easy job in my opinion, expecially nowadays with all that trees in the forest... =20 I strongly believe in D, and we have migrated all our major projects over it, but sometimes, when I'm alone with my thoughts, I not sure if the "force is strong in me" like at the beginning... =20 Well, we'll see: alea iacta est.
i believe in D too, and i want it to succeed -- not only for me. that's=20 why i'm writing here. i'm not attacking it for the sake of attack, and i=20 deliberately took the position of outcast.=
Jan 27 2015
parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Tuesday, 27 January 2015 at 09:20:51 UTC, ketmar wrote:
 i believe in D too, and i want it to succeed -- not only for 
 me. that's
 why i'm writing here. i'm not attacking it for the sake of 
 attack, and i
 deliberately took the position of outcast.
Strategically, what has your outcast position gotten you? What incentive do you have to keep on with that choice?
Jan 27 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 16:22:17 +0000, Zach the Mystic wrote:

 On Tuesday, 27 January 2015 at 09:20:51 UTC, ketmar wrote:
 i believe in D too, and i want it to succeed -- not only for me. that's
 why i'm writing here. i'm not attacking it for the sake of attack, and
 i deliberately took the position of outcast.
=20 Strategically, what has your outcast position gotten you? What incentive do you have to keep on with that choice?
i have an answer, but sorry, i prefer to not make it public.=
Jan 27 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-01-26 20:50, Walter Bright wrote:

 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.
How is this change going to help when there's still a bunch of attributes that can not be prefixed with ' ', immutable, const, public and so on? -- /Jacob Carlborg
Jan 27 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 27 Jan 2015 11:20:41 +0100, Jacob Carlborg wrote:

 On 2015-01-26 20:50, Walter Bright wrote:
=20
 It's good to have this discussion.

 Previously, it's all been advocacy and "break my code" by forcing a
 change from pure =3D>  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.
=20 How is this change going to help when there's still a bunch of attributes that can not be prefixed with ' ', immutable, const, public and so on?
who cares? it's SLASHDOT USER! i doubt that he wrote anything except=20 "helloworld" in D, but it's SLASHDOT USER! reddit and slashdot users are=20 first-class citizens for D, and actual D users are of no importance.=
Jan 27 2015
prev sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 27/01/2015 10:20, Jacob Carlborg wrote:
 How is this change going to help when there's still a bunch of
 attributes that can not be prefixed with ' ', immutable, const, public
 and so on?
Those can apply to variables too. We could use built-in attributes for functions only (https://issues.dlang.org/show_bug.cgi?id=13388#c31).
Jan 27 2015
prev sibling parent reply "Mike" <none none.com> writes:
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis 
wrote:

 if we deprecate pure and nothrow without  , then we'll be
 forced to change pretty much every D program in existence.
A trivial search and replace. Some might be against this change now, but 5 years from we'll profit from it. Mike
Jan 26 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 2:57 PM, Mike wrote:
 On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote:

 if we deprecate pure and nothrow without  , then we'll be
 forced to change pretty much every D program in existence.
A trivial search and replace. Some might be against this change now, but 5 years from we'll profit from it.
It's the continuous drip-drip-drip of this that ticks people off.
Jan 26 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2015 1:50 AM, Brian Schott wrote:
 I'm running out of ideas for DConf topics.
I don't think there's any risk of bugzilla going down to zero by May :-)
Jan 26 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 26 Jan 2015 09:29:40 +0000, Paolo Invernizzi wrote:

i'm scared. does that mean that my rants about "consistency" was sane=20
after all? and now i have to find something else to attack? (sigh) poor=20
me.=
Jan 26 2015
prev sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi 
wrote:
 If someone is not following the merges, well...  [1] !!

 ---
 Paolo

 [1] 
 http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034171 hookshot-fe4-cp1-prd.iad.github.net.mail
In case anybody was wondering, dfix has had the ability to do the "nothrow" -> " nothrow" conversion since October.
Jan 26 2015