Re: Minimizing "reserved" words
On Monday, 31 October 2016 at 20:45:56 UTC, Jacob Carlborg wrote: The "reserved" words I'm referring to are not necessarily keywords in the language but otherwise words that should be avoided, especially for defining methods in aggregates. I'm mostly thinking of built-in properties like .init, .classinfo, .sizeof, .outer and so on. All of the above can be used as variable names. Some of the above names can be used as methods in aggregates but some cannot. Of the above names only "sizeof" cannot be used as a method name. Would it be better to try to minimize these special words and instead use either compiler recognized functions/templates or something like __traits? If they were compiler recognized functions, defined somewhere in druntime, the normal language lookup rules could be used to disambiguate the compiler recognized functions from user defined functions. Or if a __trait is used, that would have it's own namespace and not cause any conflicts. In the latest release of DMD (2.072.0) TypeInfo.init has been deprecate in favor of TypeInfo.initializer. That would not have been needed if .init wasn't a built-in property but instead a compiler recognized function. Thoughts? Too late to change, to much could would break? This information from Wiki, I hope it will be useful. That general reserved words and keywords need not coincide, but in most modern languages keywords are a subset of reserved words, as this makes parsing easier, since keywords cannot be confused with identifiers. In some languages, like C or Python, reserved words and keywords coincide, while in other languages, like Java, all keywords are reserved words, but some reserved words are not keywords – these are "reserved for future use". In yet other languages, such as the older languages ALGOL, FORTRAN and PL/I, there are keywords but no reserved words, with keywords being distinguished from identifiers by other means. This makes parsing more difficult with look-ahead parsers necessary.
Re: Minimizing "reserved" words
On Tuesday, November 01, 2016 08:29:17 Jacob Carlborg via Digitalmars-d wrote: > On 2016-10-31 23:25, Jonathan M Davis via Digitalmars-d wrote: > > IMHO, it's just plain error-prone to allow for any of the built-in > > properties to be overridden, and it should be disallowed in all cases. > > We > > need to be able to rely on stuff like .init of .sizeof being the > > built-in > > property, or you're just going to get bugs - especially in generic code. > > That might be the case. But why are they built-in properties from the > beginning. Compiler recognized free functions or __traits would not have > this problem. In general, I don't think that it would make sense for them to be functions, and they'd be uglier as traits. And for the most part, they aren't names that anyone is really going to want to use for their own code anyway (particularly with the typical D naming conventions). AFAIK, the only one that's sometimes getting defined and causing problems is init, and that's certainly used often enough that needing something like __traits to use it would be rather annoying. But it's certainly true that they could have have been implemented differently originally. However, it would break far too much code at this point to change them even if we all agreed that the current situation was less than ideal. But the only built-in properties that I can think of which definitely shouldn't have been built-in proprties are the ones specific to arrays such as sort, and they've already been deprecated in favor of proper functions. So, the ones that were obviously a bad idea have already been taken care of. - Jonathan M Davis
Re: Minimizing "reserved" words
On 2016-10-31 23:25, Jonathan M Davis via Digitalmars-d wrote: IMHO, it's just plain error-prone to allow for any of the built-in properties to be overridden, and it should be disallowed in all cases. We need to be able to rely on stuff like .init of .sizeof being the built-in property, or you're just going to get bugs - especially in generic code. That might be the case. But why are they built-in properties from the beginning. Compiler recognized free functions or __traits would not have this problem. -- /Jacob Carlborg
Re: Minimizing "reserved" words
On Monday, 31 October 2016 at 20:45:56 UTC, Jacob Carlborg wrote: In the latest release of DMD (2.072.0) TypeInfo.init has been deprecate in favor of TypeInfo.initializer. That would not have been needed if .init wasn't a built-in property but instead a compiler recognized function. at least for ".init" i can't see any reason for not replacing it with ".default". we can deprecate ".init", yet allow both for some time, and ".default" is just as logical as ".init", but it is using already reserved word. it is completely unambiguous, and easy to detect in highlighting engine by checking if we have dot before it. at least this is way more logical than using `enum a = 42;` to declare a single constant instead of enumeration. ;-)
Re: Minimizing "reserved" words
On Monday, 31 October 2016 at 20:45:56 UTC, Jacob Carlborg wrote: The "reserved" words I'm referring to are not necessarily keywords in the language but otherwise words that should be avoided, especially for defining methods in aggregates. I'm mostly thinking of built-in properties like .init, .classinfo, .sizeof, .outer and so on. All of the above can be used as variable names. Some of the above names can be used as methods in aggregates but some cannot. Of the above names only "sizeof" cannot be used as a method name. classinfo, sizeof... do not match the D coding convention (which is necessary to write D code that don't conflict with built-in keywords) when used. camelCase is recommended.
Re: Minimizing "reserved" words
On Monday, October 31, 2016 22:22:00 Jacob Carlborg via Digitalmars-d wrote: > On 2016-10-31 21:53, Steven Schveighoffer wrote: > > The plan is to deprecate .init as an overridable method or field, and > > then remove support (i.e. .init ALWAYS refers to the compile-generated > > init instance). First step is for Phobos/druntime to eradicate all uses > > of it. > > I suspected this was the plan. My post was about that there are other > built-in properties that have the same problem. Also that the solution, > to not make them overridable, might not be the best solution. The > current implementation (built-in properties) don't add much advantage > but has the disadvantage of taking up an additional word as reserved. IMHO, it's just plain error-prone to allow for any of the built-in properties to be overridden, and it should be disallowed in all cases. We need to be able to rely on stuff like .init of .sizeof being the built-in property, or you're just going to get bugs - especially in generic code. I see no problem with being able to declare a variable with any of those names, and it's probably okay for them to be used as the names of free functions (and if you tried to use UFCS with them, they'd even be acting the way that UFCS normally acts in the cases where there's a conflict). It's just that they shouldn't be allowed to be declared as members of a type, because they're already there with the built-in properties. Honestly, it seems like a pretty serious bug to me that it's ever been possible to declare any of them as members. - Jonathan M Davis
Re: Minimizing "reserved" words
On 2016-10-31 21:53, Steven Schveighoffer wrote: The plan is to deprecate .init as an overridable method or field, and then remove support (i.e. .init ALWAYS refers to the compile-generated init instance). First step is for Phobos/druntime to eradicate all uses of it. I suspected this was the plan. My post was about that there are other built-in properties that have the same problem. Also that the solution, to not make them overridable, might not be the best solution. The current implementation (built-in properties) don't add much advantage but has the disadvantage of taking up an additional word as reserved. -- /Jacob Carlborg
Re: Minimizing "reserved" words
On 10/31/16 4:45 PM, Jacob Carlborg wrote: In the latest release of DMD (2.072.0) TypeInfo.init has been deprecate in favor of TypeInfo.initializer. That would not have been needed if ..init wasn't a built-in property but instead a compiler recognized function. Thoughts? Too late to change, to much could would break? The plan is to deprecate .init as an overridable method or field, and then remove support (i.e. .init ALWAYS refers to the compile-generated init instance). First step is for Phobos/druntime to eradicate all uses of it. -Steve
Minimizing "reserved" words
The "reserved" words I'm referring to are not necessarily keywords in the language but otherwise words that should be avoided, especially for defining methods in aggregates. I'm mostly thinking of built-in properties like .init, .classinfo, .sizeof, .outer and so on. All of the above can be used as variable names. Some of the above names can be used as methods in aggregates but some cannot. Of the above names only "sizeof" cannot be used as a method name. Would it be better to try to minimize these special words and instead use either compiler recognized functions/templates or something like __traits? If they were compiler recognized functions, defined somewhere in druntime, the normal language lookup rules could be used to disambiguate the compiler recognized functions from user defined functions. Or if a __trait is used, that would have it's own namespace and not cause any conflicts. In the latest release of DMD (2.072.0) TypeInfo.init has been deprecate in favor of TypeInfo.initializer. That would not have been needed if .init wasn't a built-in property but instead a compiler recognized function. Thoughts? Too late to change, to much could would break? -- /Jacob Carlborg
