• bearophile <bearophileHUGS lycos.com> Mar 27 2008
• e-t172 <e-t172 akegroup.org> Mar 27 2008
• bearophile <bearophileHUGS lycos.com> Mar 27 2008

bearophile <bearophileHUGS lycos.com> writes:

Benji Smith:
 Const is a total trainwreck, and is the biggest reason for me to stay 
 away from D in a real project.


Now You can use D 1.x. And I think that eventually D developers will understand
that the current const regime may be not practical enough.


 The existence of three different string types (six, if you count 
 const/mutable variations of each) makes text-processing more difficult 
 than it ought to be.
 I would have liked to see just one string type, with encoding kept as an 
 internal implementation detail. And I'd much rather have a string class 
 than to treat strings as character arrays (especially since 
 indexing/slicing deals with code-points rather than character positions).


I think Python 3.0 (despite being a very different language with quite
different purposes) shows a good solution: a (probably mutable) byte array (or
maybe two of them, one mutable and one immutable) plus an unicode (immutable)
string class. Those two are probably enough for many situations.
But currently on 32 bit systems an empty string is a struct that needs 4+4
bytes only, while a string class probably requires more, it may be slower, etc.


 The mandate to keep keyword count as low as possible has been a real 
 detriment to the language.
 Each unique concept should have its own unique keyword.


I agree. I am not scared of more keywords, if they help keep the language more
clean.


 1) There's a gap in functionality between static arrays (whose size must 
 be known at compile time) and growable dynamic arrays.


Their semantics is a bit tricky, try to loop on an AA with static arrays as
keys, etc.


 Most often, what I really want is a non-growable array whose size isn't 
 known until runtime, but D doesn't have that concept


You can create such "concept", it's not too much difficult to write such
class/struct. I have already done it, TinyVector, a struct that you can use
that is useful when running speed is the most important thing.


I also would have preferred to have growable arrays and associative arrays in
the standard library than in the language.<


Having a built-in AA is really useful in many situations (but I agree it has
some downsides too).


 I don't want to memorize a bunch of loopholes. I want a straightforward
 language that makes sense, right out of the box.


Even if no one has answered my post:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=68070
It seems you are saying the same thing: the most important thing for D now is
probably to reduce the number of its corner cases.

Bye,
bearophile

e-t172 <e-t172 akegroup.org> writes:

bearophile a écrit :
 Most often, what I really want is a non-growable array whose size isn't 
 known until runtime, but D doesn't have that concept


 You can create such "concept", it's not too much difficult to write such
class/struct. I have already done it, TinyVector, a struct that you can use
that is useful when running speed is the most important thing.


We are talking about builtin language features here, IMHO saying "you 
can write a class/template for that" is a little off point.

bearophile <bearophileHUGS lycos.com> writes:

e-t172:
 We are talking about builtin language features here, IMHO saying "you 
 can write a class/template for that" is a little off point.


The most common data structures can be built-in, while the less common (or the
ones that don't need a special syntax) can be in the std lib. A third type of
built-in array is overkill, because I think that (given the other two) it's not
necessary often enough (its advantages are little, and you can import a
class/struct with good operator overloading that has a good enough syntax),
while I think built in set and "packed list" can be more useful.
But I agree that abstract interfaces too can be useful (so you can define the
idea of something iterable, something that acts as an associative array,
something that acts as a set, etc and then you can create a function that takes
as input something that for example conforms to the iterable semantics plus the
associative array semantics, despite not being a built-in AA).

Bye,
bearophile