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
next sibling 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=


 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=

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

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

 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 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

 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

outer length. Allow only $.


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

 outer length. Allow only $.


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

 outer length. Allow only $.


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 parent "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

 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
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)

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