On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote:
When designing D libraries than lean towards DSL style, I've
frequently felt impaired by the lack of implicit conversions in
D. In my experience, it's not that all types need to be
implicitly convertible to other types. Just being able to mark
a few types as implicitly convertible to some other specific
types would go a long way to alleviate the limitations I felt.
It would also solve problems like an arbitrary limit on the
depth of implicit conversions.
I had imagined that maybe one day an implicit keyword could be
introduced to mark such permissible implicit conversions.
Seeing an implicit "keyword" being introduced here with
different semantics than I envisioned makes me even less
hopeful that some day such implicit conversions annotations
could be introduced. So... maybe consider choosing some other
syntactic notation? Besides, the fact that the compiler can
implicitly introduce calls to the copy ctor doesn't strike me
as something particularly central to the concept, so it seems
like an odd choice for something to distinguish a copy ctor.
More details. The DIP says:
"The structName type needs to be identical to typeof(this); an
error is issued otherwise. This requirement may be relaxed in the
future in order to accomodate copying from objects of a different
type"
(BTW, typo in "accomodate")
That would mean that if such a relaxation were introduced, then
suddenly *all* copy ctors would imply implicit conversion between
the respective types. Given D's stance on implicit conversions, I
suspect that's not going to pass mustard. So I would prefer the
any "implicit" keyword-like annotation to be reserved for
explicitly approved implicit conversions.
