digitalmars.D - Re: Why I (Still) Won't Use D
- bearophile <bearophileHUGS lycos.com> Mar 27 2008
- e-t172 <e-t172 akegroup.org> Mar 27 2008
- bearophile <bearophileHUGS lycos.com> Mar 27 2008
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
Mar 27 2008
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.
Mar 27 2008
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
Mar 27 2008