www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - de facto keywords

reply Paul D. Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
It seems to me there exist a few "unofficial" keywords in D that should be
promoted to reserved words:

"string", "dstring", "wstring" -- I'm assuming that backward compatibility is
the only reason these are not declared as keywords. Is there more to it than
that?

"tuple" -- The use of tuples is ubiquitous in D. There is a a "tupleof"
property for structs and unions. The "foreach" keyword knows about them. Yet
there is no syntactic support for the thing itself. It is confusing to be
required to define a template to access something the compiler creates. This
may be just syntactic sugar but it's necessary sugar, IMHO.

Paul
Apr 05 2008
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 05/04/2008, Paul D. Anderson
<paul.d.anderson.removethis comcast.andthis.net> wrote:

  "tuple" -- The use of tuples is ubiquitous in D. There is a a "tupleof"
property for structs and unions. The "foreach" keyword knows about them. Yet
there is no syntactic support for the thing itself. It is confusing to be
required to define a template to access something the compiler creates. This
may be just syntactic sugar but it's necessary sugar, IMHO.


In fact, the word "tuple" is ambiguous in D. If you believe the
article "Tuples" on the digitalmars website then a tuple is a sequence
of a mix of types and values, whereas if you believe the documentation
for std.typecons then a Tuple! is an aggregate of values (so that a
function can return multiple values, for example).

In all computer languages of which I am aware, the word "tuple"
normally has the latter meaning. The former meaning is perhaps better
described by the phrase "variadic template arguments". I have
submitted a bug report pointing out the ambiguity, and maybe the
documentation should be fixed one day.
Apr 05 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Paul D. Anderson wrote:

 It seems to me there exist a few "unofficial" keywords in D that should be
promoted to reserved words:
 
 "string", "dstring", "wstring" -- I'm assuming that backward compatibility is
the only reason these are not declared as keywords. Is there more to it than
that?


These are aliases in the library. They have as much right to be keywords 
as "Socket" or "printf".


 "tuple" -- The use of tuples is ubiquitous in D. There is a a "tupleof"
property for structs and unions. The "foreach" keyword knows about them. Yet
there is no syntactic support for the thing itself. It is confusing to be
required to define a template to access something the compiler creates. This
may be just syntactic sugar but it's necessary sugar, IMHO.


I agree there should be syntactic support for tuples, but I don't think 
the "tuple" keyword is best. Instead, what about (int, float, 3) being a 
  tuple?


 Paul


The _real_ de facto keyword is the word "length" since when it's used 
inside an array index it shadows any variable called "length" outside.
Apr 05 2008
parent reply Paul D. Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
Robert Fraser Wrote:


 Paul D. Anderson wrote:

 It seems to me there exist a few "unofficial" keywords in D that should be
promoted to reserved words:
 
 "string", "dstring", "wstring" -- I'm assuming that backward compatibility is
the only reason these are not declared as keywords. Is there more to it than
that?


 
 These are aliases in the library. They have as much right to be keywords 
 as "Socket" or "printf".
 


I'm aware they are aliases. My concern is that they are so common in the
library that anyone who deliberately (or worse, ignorantly) uses them somewhere
else is likely to have problems. The way to avoid these problems (IMHO) is to
reserve the words. 


 "tuple" -- The use of tuples is ubiquitous in D. There is a a "tupleof"
property for structs and unions. The "foreach" keyword knows about them. Yet
there is no syntactic support for the thing itself. It is confusing to be
required to define a template to access something the compiler creates. This
may be just syntactic sugar but it's necessary sugar, IMHO.


 
 I agree there should be syntactic support for tuples, but I don't think 
 the "tuple" keyword is best. Instead, what about (int, float, 3) being a 
   tuple?
 


My personal preference is for a keyword rather than a syntactic interpretation,
but I wouldn't object to the change you describe. My gripe is with the reliance
on a template for access to fundamental constructs.



 Paul


 
 The _real_ de facto keyword is the word "length" since when it's used 
 inside an array index it shadows any variable called "length" outside.


I agree, but I can hear the screams from the populace who have used "length"
all over their code. All the more reason, IMO, to make the change now.

Paul
Apr 05 2008
next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 05/04/2008, Paul D. Anderson
<paul.d.anderson.removethis comcast.andthis.net> >  > I agree there
should be syntactic support for tuples, but I don't think

  > the "tuple" keyword is best. Instead, what about (int, float, 3) being a
  >   tuple?


I use std.typecons.Tuple quite a lot (...ever since I discovered it!),
as it allows functions to return multiple values.

I dislike the /other/ meaning "tuple", which is a random mix of types
and values - e.g. (int, float, 3). I'd rather they were called
something else - if indeed they need a name at all! (I suspect they
don't. The phrase "variadic template parameters" describes what they
are just fine).
Apr 05 2008
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Paul D. Anderson wrote:

 The _real_ de facto keyword is the word "length" since when it's used 
 inside an array index it shadows any variable called "length" outside.


 
 I agree, but I can hear the screams from the populace who have used "length"
all over their code. All the more reason, IMO, to make the change now.
 
 Paul


The idea I saw before was to remove "length" as a specifier within array 
  indexes, and just use "$".
Apr 05 2008