On 7/12/18 7:15 PM, Manu wrote:
On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
On 07/12/2018 11:14 AM, Luís Marques wrote:
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.
No, only constructors annotated with @implicit would be implicit. But
that's only a possible future direction not part of this DIP.
Also there are many complications related to allowing implicit
conversions across distinct types, and this DIP should not get embroiled
in those. That would be a different pursuit that I encourage you to
consider.
I feel like this DIP depends on an @implicit DIP, and that one needs
to come first...
Negative.
