On Sunday, 13 February 2022 at 01:27:45 UTC, Ali Çehreli wrote:
[...]
> If I remove the constraint (the if-stuff) I get
>
> v1.d(12): Error: cannot implicitly convert expression
`kv.value()`
> of type `byte` to `string`
> v1.d(23): Error: template instance
`v1.update!(string[int],
> byte[short])` error instantiating
That's inferior because now the error message is pointing at
the implementation of a library function and confuses everyone.
It confuses me not really. (Function) templates are by their very
nature
visible to the user and I got used to reading the implementations.
Nonetheless may the compiler-generated checks be moved into the
interface:
void update(Target, From)(ref Target target, From from, Target
dummy = From.init)
For this function template dmd reports in case of incompatible
types:
cannot implicitly convert expression `null` of type
`byte[short]` to `string[int]`
[...]
After all, everything that the programmer needs is spelled out
here. It requires following some types:
with `Target = string[int],
From = byte[short]`
must satisfy the following constraint:
isImplicitlyConvertible!(ValueType!From,
ValueType!Target)`
The only thing that's not readily available there is ValueType
but at least it's very readable.
The constraints appear artificial to me: Neither are there means
which ensure
that a list of Constraints is complete nor is it ensured that a
list of
constraints is not overly restrictive. It seems that these
Constraints constitute
another class of things which may get out of sync with the actual
code (besides program documentation, program comments and
function names).
Doesn't this re-iteration of what is already implicitly contained
in the line
target[kv.key] = kv.value;
violate the DRY principle?
