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.

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

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.

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.

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?

-- Simen

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

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]... :-)

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

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.

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.