www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Minimizing "reserved" words

reply Jacob Carlborg <doob me.com> writes:
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
Oct 31 2016
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Oct 31 2016
parent reply Jacob Carlborg <doob me.com> writes:
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
Oct 31 2016
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Oct 31 2016
parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 01 2016
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
Nov 01 2016
prev sibling next sibling parent Karabuta <karabutaworld gmail.com> writes:
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.
Oct 31 2016
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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. ;-)
Oct 31 2016
prev sibling parent Daniel9 <andreikovalsa mail.ru> writes:
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.
Nov 01 2016