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