Implicit conversion to mutable if no indirections?

Loara loara at noreply.com
Tue Sep 6 11:09:26 UTC 2022


On Tuesday, 6 September 2022 at 10:06:59 UTC, Quirin Schroll 
wrote:

> * Aforementioned `const(int*)` becoming `const(int)*`. That 
> does not happen with custom `struct S(T)` automatically even in 
> cases where it is provably correct, and there is no way to tell 
> the D compiler that copies of `const(S!int)` are better 
> understood to be `S!(const int)`.

Consider
```d
struct S(T){
   T val;
   int idx;

   void inc(){
     idx++;
   }
}
```
then `s.inc()` is valid if `s` id `S!(const int)` but not if `s` 
is `const S!int`!

Again consider
```d
struct S(T){
    int dat;
    T func(T dat){ ... }
}
```
in this example conversion of `S!(const int)` to `const S!int` 
has much less sense. If you want to perform a such conversion 
then you should instead introduce a "cloning" method:

```d
auto clone() const pure{
   return S(...);
}
```

> * Types are keywords: With `alias` we could have `alias int = 
> __traits(signed_integer_type, 32);` etc. There were a lot of 
> issues in the parser that could be avoided. If you think this 
> leads to problems, note that `string` is such an alias already.
> * Type constructors are hard-wired: If templates want to 
> deconstruct a type, a lot of special cases have to be written 
> because in `int*`, `int[]`, `int[10]`, and `int[string]`, the 
> `*`, `[]`, `[N]`, `[T]` is not syntactic sugar for 
> (hypothetical) `Ptr!int`, `Slice!int`, `Array!(int, 10)`, and 
> `AssocArray!(string, int)`, respectively, so those would be 
> matched by `void f(alias TT, T)(TT!T value)`.

Traits exists for this reason: provide a common interface for 
hard wired types and templated ones.





More information about the Digitalmars-d mailing list