| |
 | Posted by Andrei Alexandrescu
in reply to Walter Bright |  Permalink Reply |
|
Andrei Alexandrescu 
Posted in reply to Walter Bright
| On 2021-11-01 17:41, Walter Bright wrote:
> On 11/1/2021 9:18 AM, deadalnix wrote:
>> This part IMO, point at what the #1 problem with the way things have been done in D. D's feature just don't compose well because they aren't orthogonal with each other (and many are inconsistent).
>
> Can you be more specific?
>
> Some examples of consistency in D:
There are easily found counterpoints even to your examples.
> 1. basic types, structs, and arrays are interchangeable. But I couldn't add tuples to the list, because the function call ABI for structs is "special". Urgh.
1a. Hash tables have a number of language magic hacks (particularly concerning keys that have statically-sized array types) that are thoroughly inconsistent with the language rules.
> 2. The nature of how const, immmutable, and shared are applied to types is completely consistent, despite many requests to change that.
2a. Hash tables have any number of qualifier-related hacks that makes them impossible to implement as a library.
2b. Calls to built-in arrays remove the top-level qualifier in a way that is not accessible to user code. This makes qualified ranges impossible to implement:
void fun(T)(T data) {
import std;
writeln(T.stringof);
}
void main() {
immutable int a = 42;
immutable int[] b = [ 69 ];
fun(a); // fine, prints immutable(int)
fun(b); // prints immutable(int)[], not immutable(int[])
}
2c. There are a number of hacks in the compiler that give special treatment to shared numerics. Such is inaccessible to user code. Worse, they don't generate correct code.
void main() {
shared int i = 42;
i = i + 2; // whatta?
}
> 4. The way scope & return & ref apply to types is completely consistent. This enables me to advise that when people have problems understanding it, to rewrite their example code in terms of raw pointers, as it will behave the same.
I very much wish this is true and useful.
|
