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.

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.

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

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

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

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

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

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

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)

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