www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A few simple syntactic proposals

reply Robert Fraser <fraserofthenight gmail.com> writes:
Okay, I read the "handling constructive criticism" topic and Walter's 
reply where he suggests that proposals should go into bugzilla. Based on 
that, I want to start a topic on _MINOR_ changes to the syntax and 
semantics of D that most people should agree upon. If there's any 
objection to these at all, it probably warrants more discussion before 
going into bugzilla, but otherwise these should be added as bugs.

All of these proposals apply to D2 only. D1 needs to remain as stable as 
possible, IMO, though a few of these might be candidates for backporting.

I'll start us off with 3 off the top of my head:

1. Remove "delete aa[key]" as a syntactic equivalent to "aa.delete(key)" 
for associative arrays. It's been deprecated in both branches of D but 
needs to go from D2, since it goes against the D philosophy of 
unambiguous parsing without semantic analysis.

2. Allow interfaces that are not sub-interfaces of IUnknown to be 
explicitly "delete"d.

3. String literals should be typed as dynamic arrays. This would mean 
that "foo" would be of type invariant(char)[] not type 
invariant(char)[3u] . Note that this would have the disadvantage of 
requiring an explicit cast if the string literal were to be needed as a 
static array, but how many times have you actually used a string literal 
to initialize a static array (or used a static array at all...?)

Anyone has the right to veto any proposal here, but if there aren't any 
vetos I may add them to bugzilla.
Apr 16 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Robert Fraser wrote:

 Okay, I read the "handling constructive criticism" topic and Walter's 
 reply where he suggests that proposals should go into bugzilla. Based on 
 that, I want to start a topic on _MINOR_ changes to the syntax and 
 semantics of D that most people should agree upon. If there's any 
 objection to these at all, it probably warrants more discussion before 
 going into bugzilla, but otherwise these should be added as bugs.
 
 All of these proposals apply to D2 only. D1 needs to remain as stable as 
 possible, IMO, though a few of these might be candidates for backporting.
 
 I'll start us off with 3 off the top of my head:
 
 [...]


Also:
Remove the implicit "length" inside slice brackets as it conflicts with 
outer length. Allow only $.
Apr 16 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Robert Fraser wrote:

 Also:
 Remove the implicit "length" inside slice brackets as it conflicts with
 outer length. Allow only $.


Can you give an example of this?

are you saying char[] foo = bar[3..length] should be replaced with char[]
foo = bar[3..$]?  If yes, I don't see how the length is confusing.  If
you're talking about nested indexing, I'd expect both length and $ to be
ambiguous.
Apr 16 2008
next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 17 Apr 2008 04:01:56 +0200, Jason House  =

<jason.james.house gmail.com> wrote:


 Robert Fraser wrote:

 Also:
 Remove the implicit "length" inside slice brackets as it conflicts wi=




th

 outer length. Allow only $.


 Can you give an example of this?

 are you saying char[] foo =3D bar[3..length] should be replaced with c=


har[]

 foo =3D bar[3..$]?  If yes, I don't see how the length is confusing.  =


If

 you're talking about nested indexing, I'd expect both length and $ to =


be

 ambiguous.



int length =3D 4;
int[] foo;

// ...

auto bar =3D foo[0..length];


will this slice from 0 to foo.length or 0 to 4?

-- Simen
Apr 16 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Simen Kjaeraas wrote:

 On Thu, 17 Apr 2008 04:01:56 +0200, Jason House 
 <jason.james.house gmail.com> wrote:
 

 Robert Fraser wrote:

 Also:
 Remove the implicit "length" inside slice brackets as it conflicts with
 outer length. Allow only $.


 Can you give an example of this?

 are you saying char[] foo = bar[3..length] should be replaced with char[]
 foo = bar[3..$]?  If yes, I don't see how the length is confusing.  If
 you're talking about nested indexing, I'd expect both length and $ to be
 ambiguous.


 
 
 int length = 4;
 int[] foo;
 
 // ...
 
 auto bar = foo[0..length];
 
 
 will this slice from 0 to foo.length or 0 to 4?


The argument is that 'length' is a "stealth keyword".
It's not an official keyword, but you can't really use it for variable 
names because they'll conflict with that implicit 'length' inside brackets.

Just using $ always for slicing solves that since $ is never a legal 
variable name.  Besides, do we really need two ways to do exactly the 
same thing?  I've never used "length" in indexing in D because I'm never 
sure what it's going to do (many of my structs have a length property to 
mimic built-in arrays -- if I say foo[0..length] in a method of that 
struct which 'length' will it use?), and because $ is a lot less to type.

--bb
Apr 16 2008
parent Tomasz Sowinski <tomeksowi gmail.com> writes:
Bill Baxter Wrote:


 The argument is that 'length' is a "stealth keyword".
 It's not an official keyword, but you can't really use it for variable 
 names because they'll conflict with that implicit 'length' inside brackets.
 
 Just using $ always for slicing solves that since $ is never a legal 
 variable name.  Besides, do we really need two ways to do exactly the 
 same thing?  I've never used "length" in indexing in D because I'm never 
 sure what it's going to do (many of my structs have a length property to 
 mimic built-in arrays -- if I say foo[0..length] in a method of that 
 struct which 'length' will it use?), and because $ is a lot less to type.
 


I totally agree - I expect short names inside [..], like i, j, k, maybe "min",
but "length" is just ugly and you somehow stop noticing it's a slice - the
squared brackets start to look so small if you have something that big inside.

array[3..$] should be the only way.

Tomek
Apr 17 2008
prev sibling parent reply "Scott S. McCoy" <tag cpan.org> writes:
On Wed, 2008-04-16 at 22:01 -0400, Jason House wrote:

 

 Remove the implicit "length" inside slice brackets as it conflicts


 with

 outer length. Allow only $.




The conflict is irrelevant.  I vote +1 for ditching "length" as a
magical keyword inside a slice index.

Although I still wish we had [..], [0..] [..N]... :-)
Apr 16 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Scott S. McCoy wrote:

 On Wed, 2008-04-16 at 22:01 -0400, Jason House wrote:

 Remove the implicit "length" inside slice brackets as it conflicts


 with

 outer length. Allow only $.




 
 The conflict is irrelevant.  I vote +1 for ditching "length" as a
 magical keyword inside a slice index.
 
 Although I still wish we had [..], [0..] [..N]... :-)


That's a really good idea, and I haven't seen that posted before. I'll 
suggest that one too unless there's any objection. If a lower expression 
is omitted, it will automatically be converted to "0" and if an upper 
expression is missing it will automatically be converted to "$". Might 
be a little easier to make mistakes with, though.
Apr 17 2008
parent Leandro Lucarella <llucax gmail.com> writes:
Robert Fraser, el 17 de abril a las 01:15 me escribiste:

 Scott S. McCoy wrote:

On Wed, 2008-04-16 at 22:01 -0400, Jason House wrote:

Remove the implicit "length" inside slice brackets as it conflicts


with

outer length. Allow only $.




The conflict is irrelevant.  I vote +1 for ditching "length" as a
magical keyword inside a slice index.
Although I still wish we had [..], [0..] [..N]... :-)


 
 That's a really good idea, and I haven't seen that posted before. I'll suggest
that one too unless there's any objection. If a lower expression is omitted, it 
 will automatically be converted to "0" and if an upper expression is missing
it will automatically be converted to "$". Might be a little easier to make 
 mistakes with, though.


There were a whole thread on that, and it wasn't well received for several
reasons. I can't find the thread now.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Si pusieramos la máquina de cortar boludos dentro de la máquina del tiempo
y se pusiera a cortar boludos históricos con retroactividad,
otra sería la historieta hoy.
	-- Tato Bores
Apr 17 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Scott S. McCoy (tag cpan.org)'s article

 On Wed, 2008-04-16 at 22:01 -0400, Jason House wrote:

 Remove the implicit "length" inside slice brackets as it conflicts


 with

 outer length. Allow only $.




 The conflict is irrelevant.  I vote +1 for ditching "length" as a
 magical keyword inside a slice index.
 Although I still wish we had [..], [0..] [..N]... :-)


That reminds me... drop the dual meaning of "auto".  The old meaning
has hung on for far too long.


Sean
Apr 17 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Sean Kelly wrote:

 == Quote from Scott S. McCoy (tag cpan.org)'s article

 On Wed, 2008-04-16 at 22:01 -0400, Jason House wrote:

 Remove the implicit "length" inside slice brackets as it conflicts


 with

 outer length. Allow only $.




 The conflict is irrelevant.  I vote +1 for ditching "length" as a
 magical keyword inside a slice index.
 Although I still wish we had [..], [0..] [..N]... :-)


 
 That reminds me... drop the dual meaning of "auto".  The old meaning
 has hung on for far too long.
 
 
 Sean


That's another really good one. Especially with other storage classes, 
it can be a real killer when "const auto S = ...;" doesn't mean the same 
thing as "const S = ...;".
Apr 18 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Robert Fraser wrote:

 3. String literals should be typed as dynamic arrays. This would mean
 that "foo" would be of type invariant(char)[] not type
 invariant(char)[3u] . Note that this would have the disadvantage of
 requiring an explicit cast if the string literal were to be needed as a
 static array, but how many times have you actually used a string literal
 to initialize a static array (or used a static array at all...?)


I'm not vetoing this, but I will say that I don't really appreciate why this
is a problem.  I also wonder if there's a more generic problem about
handling of static vs. dynamic arrays.
Apr 16 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jason House wrote:

 Robert Fraser wrote:

 3. String literals should be typed as dynamic arrays. This would mean
 that "foo" would be of type invariant(char)[] not type
 invariant(char)[3u] . Note that this would have the disadvantage of
 requiring an explicit cast if the string literal were to be needed as a
 static array, but how many times have you actually used a string literal
 to initialize a static array (or used a static array at all...?)


 
 I'm not vetoing this, but I will say that I don't really appreciate why this
 is a problem.  I also wonder if there's a more generic problem about
 handling of static vs. dynamic arrays.


There are major static array problems, and I actually created this topic 
so that someone with more experience working with D than I have can come 
and suggest the _real_ fixes that are needed.

The only time I've run into the problem is in array declarations, but I 
know it's also a problem for template metaprogramming. An example of the 
array thing is declaring a literal array of strings:

auto cities = [ "New York", "London", "Paris", "Tokyo" ]

This will fail to compile notmally. You need to use:


auto cities = [ "New York"[], "London", "Paris", "Tokyo" ]

... but this is something that might trip a new user up.
Apr 17 2008
parent reply e-t172 <e-t172 akegroup.org> writes:
Robert Fraser a écrit :

 The only time I've run into the problem is in array declarations, but I 
 know it's also a problem for template metaprogramming. An example of the 
 array thing is declaring a literal array of strings:
 
 auto cities = [ "New York", "London", "Paris", "Tokyo" ]


It will compile if you replace "auto" by "char[][]":

char[][] cities = [ "New York", "London", "Paris", "Tokyo" ];

This solves the problem, I guess, because the "char[][]" removes the 
static/dynamic array ambiguity.
Apr 17 2008
parent "Hans W. Uhlig" <huhlig gmail.com> writes:
e-t172 wrote:

 Robert Fraser a écrit :

 The only time I've run into the problem is in array declarations, but 
 I know it's also a problem for template metaprogramming. An example of 
 the array thing is declaring a literal array of strings:

 auto cities = [ "New York", "London", "Paris", "Tokyo" ]


 
 It will compile if you replace "auto" by "char[][]":
 
 char[][] cities = [ "New York", "London", "Paris", "Tokyo" ];
 
 This solves the problem, I guess, because the "char[][]" removes the 
 static/dynamic array ambiguity.


a reason auto is bad :)
ambiguity is the program killer
Apr 18 2008
prev sibling next sibling parent reply "Scott S. McCoy" <tag cpan.org> writes:
On Wed, 2008-04-16 at 17:38 -0700, Robert Fraser wrote:

 
 2. Allow interfaces that are not sub-interfaces of IUnknown to be 
 explicitly "delete"d.


Could you maybe elaborate on this a bit?  Maybe it's just because I
don't yet have the full D 2.0 proposed specification memorized, but what
on earth are you talking about? :-)
Apr 16 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Scott S. McCoy wrote:

 On Wed, 2008-04-16 at 17:38 -0700, Robert Fraser wrote:

 2. Allow interfaces that are not sub-interfaces of IUnknown to be 
 explicitly "delete"d.


 
 Could you maybe elaborate on this a bit?  Maybe it's just because I
 don't yet have the full D 2.0 proposed specification memorized, but what
 on earth are you talking about? :-)


Sure. Say you have this:

""
interface Lolcat { }

class Happycat : Lolcat { }

int main(string[] args)
{
     Lolcat cat = new Happycat();
     // ...
     delete cat; // Right now, this is illegal
}
""

The proposal is to make it legal to explicitly delete instances of an 
interface. It is illegal right now because interfaces can refer to a COM 
interface, which is not managed by D memory. But all COM interfaces are 
sub-interfaces of IUnknown so it's known at compile-time that they are 
so, thus the restriction can be applied only to them.

Also, the more I think about it, extern(C++) interfaces might not be 
easily deletable, but again this is known at compile time, so delete can 
be restricted on them as well.
Apr 17 2008
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Robert Fraser wrote:

 1. Remove "delete aa[key]" as a syntactic equivalent to "aa.delete(key)" 
 for associative arrays. It's been deprecated in both branches of D but 
 needs to go from D2, since it goes against the D philosophy of 
 unambiguous parsing without semantic analysis.


I don't think anyone uses the former expression anymore. It's unclear.


 2. Allow interfaces that are not sub-interfaces of IUnknown to be 
 explicitly "delete"d.


Just make all interface variables implicitly typed Object as well. Or 
make an IObject interface that Object and all interfaces inherit from, 
then make delete take an IObject as well.

Then you can have IUnknown not inherit from IObject if you want.


 3. String literals should be typed as dynamic arrays. This would mean 
 that "foo" would be of type invariant(char)[] not type 
 invariant(char)[3u] . Note that this would have the disadvantage of 
 requiring an explicit cast if the string literal were to be needed as a 
 static array, but how many times have you actually used a string literal 
 to initialize a static array (or used a static array at all...?)


This is indeed annoying. IFTI gets you static array types unless you use 
[], and there was that old issue with arrays and associative arrays (and 
it still exists if you use auto).
Apr 17 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Christopher Wright wrote:

 Robert Fraser wrote:

 2. Allow interfaces that are not sub-interfaces of IUnknown to be 
 explicitly "delete"d.


 
 Just make all interface variables implicitly typed Object as well. Or 
 make an IObject interface that Object and all interfaces inherit from, 
 then make delete take an IObject as well.
 
 Then you can have IUnknown not inherit from IObject if you want.


Yup, that's how it should be implemented. Unless you're suggesting make 
users rewrite all their code so that their interfaces extend IObject, in 
which case I object. (that was kind of lame)
Apr 18 2008
parent Yigal Chripun <yigal100 gmail.com> writes:
Robert Fraser wrote:

 Christopher Wright wrote:

 Robert Fraser wrote:

 2. Allow interfaces that are not sub-interfaces of IUnknown to be
 explicitly "delete"d.


 Just make all interface variables implicitly typed Object as well. Or
 make an IObject interface that Object and all interfaces inherit
 from, then make delete take an IObject as well.

 Then you can have IUnknown not inherit from IObject if you want.


 Yup, that's how it should be implemented. Unless you're suggesting
 make users rewrite all their code so that their interfaces extend
 IObject, in which case I object. (that was kind of lame)


Also, to add to Robert's post - This also applies to classes:
if you define the IObject interface all classes would inherit from it
and would have to provide implementation for it instead of just
inheriting the implementation from Object.
the best solution for this IMO is Christopher's first idea - make all
interfaces subtypes of object.
-- Yigal
Apr 18 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Robert Fraser (fraserofthenight gmail.com)'s article

 Okay, I read the "handling constructive criticism" topic and Walter's
 reply where he suggests that proposals should go into bugzilla. Based on
 that, I want to start a topic on _MINOR_ changes to the syntax and
 semantics of D that most people should agree upon. If there's any
 objection to these at all, it probably warrants more discussion before
 going into bugzilla, but otherwise these should be added as bugs.
 All of these proposals apply to D2 only. D1 needs to remain as stable as
 possible, IMO, though a few of these might be candidates for backporting.
 I'll start us off with 3 off the top of my head:
 1. Remove "delete aa[key]" as a syntactic equivalent to "aa.delete(key)"
 for associative arrays. It's been deprecated in both branches of D but
 needs to go from D2, since it goes against the D philosophy of
 unambiguous parsing without semantic analysis.
 2. Allow interfaces that are not sub-interfaces of IUnknown to be
 explicitly "delete"d.
 3. String literals should be typed as dynamic arrays. This would mean
 that "foo" would be of type invariant(char)[] not type
 invariant(char)[3u] . Note that this would have the disadvantage of
 requiring an explicit cast if the string literal were to be needed as a
 static array, but how many times have you actually used a string literal
 to initialize a static array (or used a static array at all...?)
 Anyone has the right to veto any proposal here, but if there aren't any
 vetos I may add them to bugzilla.


I'm not sure it's sufficiently simple, but a while back I suggested making
constructors inherited by default.  Here's the link:

http://www.digitalmars.com/d/archives/digitalmars/D/Inheriting_constructors_54088.html

For simple stuff, I'd like to see opEquals return a bool if it doesn't already
in D 2.0.  Also, I'd like closures to be given some attention.  Currently, they
seem to allocate too often for non-escaping closures.  This needs to be
looked at and if syntax must be added to override the automatic allocation
then it should be done sooner than later.


Sean
Apr 17 2008
parent "Koroskin Denis" <2korden gmail.com> writes:
On Thu, 17 Apr 2008 18:33:35 +0400, Sean Kelly <sean invisibleduck.org>  
wrote:

 [snip]
 I'm not sure it's sufficiently simple, but a while back I suggested  
 making
 constructors inherited by default.  Here's the link:

 http://www.digitalmars.com/d/archives/digitalmars/D/Inheriting_constructors_54088.html

 For simple stuff, I'd like to see opEquals return a bool if it doesn't  
 already
 in D 2.0.  Also, I'd like closures to be given some attention.   
 Currently, they
 seem to allocate too often for non-escaping closures.  This needs to be
 looked at and if syntax must be added to override the automatic  
 allocation
 then it should be done sooner than later.


 Sean


Hey, good idea! And the feature gets its way to C++0x, too, but not  
implicitly:
(example from wikipedia)

class BaseClass
{
public:
   BaseClass(int iValue);
};

class DerivedClass : public BaseClass
{
public:
   using default BaseClass;
// same as
//  DerivedClass(int iValue) : BaseClass(iValue) {}
};

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Apr 18 2008
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Robert Fraser, el 16 de abril a las 17:38 me escribiste:

 Anyone has the right to veto any proposal here, but if there aren't any vetos
I may add them to bugzilla.


I think you should define an ending date for discussion, otherwise this
thread will be probably lost in infinite suggestions/discussions and will
never be included in the bugzilla.

Even more, I think there should be one thread per proposal, so it's easier
to see which proposal have "vetos" and which not.

And adding stuff to bugzilla is not such a big thing, you can add it
anyways and if the proposal seems to be rejected, the bug is closed with
WONTFIX, with the advantage of being there for future reference. If
somebody want to propose something again in the future, he can see in the
bugzilla why it was rejected.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Lo último que hay que pensar es que se desalinea la memoria
Hay que priorizar como causa la idiotez propia
Ya lo tengo asumido
	-- Pablete, filósofo contemporáneo desconocido
Apr 17 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Leandro Lucarella wrote:

 Robert Fraser, el 16 de abril a las 17:38 me escribiste:

 Anyone has the right to veto any proposal here, but if there aren't any vetos
I may add them to bugzilla.


 
 I think you should define an ending date for discussion, otherwise this
 thread will be probably lost in infinite suggestions/discussions and will
 never be included in the bugzilla.
 
 Even more, I think there should be one thread per proposal, so it's easier
 to see which proposal have "vetos" and which not.
 
 And adding stuff to bugzilla is not such a big thing, you can add it
 anyways and if the proposal seems to be rejected, the bug is closed with
 WONTFIX, with the advantage of being there for future reference. If
 somebody want to propose something again in the future, he can see in the
 bugzilla why it was rejected.


I agree with you. This topic was probably a bad idea, but it seems like 
a lot of these complaints/suggestions on here are not being submitted to 
bugzilla, contrary to Walter's suggestion. I wanted to do something 
proactive about that. I also wanted to group non-controversial proposals 
(of course, from what I remember, const-by-default was nearly 
non-controversial and that didn't make it, so...).

I think you're right, though -- I'll just go ahead and add my 
suggestions (after looking through all the enhancement requests there; 
there are quite a few Walter shot down but weren't marked WONTFIX on 
bugzilla).
Apr 18 2008