Strange implicit conversion integers on concatenation

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Nov 5 23:00:23 UTC 2018


On Monday, November 5, 2018 3:08:24 PM MST 12345swordy via Digitalmars-d 
wrote:
> We need to avoid the situation where we have to create a DIP for
> every unwanted implicit conversion with regards to calling the
> wrong overload function, we need
> better way of doing this. No one wants to wait a year for a DIP
> approval for something that is very minor such as deprecating a
> implicit conversion for native data types.
>
> I think a better course of action is to introduce the keywords
> explicit and implicit. Not as attributes though! I don't want to
> see functions with @nogc @nothrow safe pure @explicit as that is
> too much verbiage and hard to read! Which brings up the question
> of which parameter exactly is explicit?
>
> It much easier to read: void example(int bar, explicit int bob)
>
> The explicit keyword will become very important if we are to
> introduce the implicit keyword, as both of them are instrumental
> in creating types with structs.
>
> I don't mind writing a DIP regarding this, as I think this is
> much easier for the DIP to be accepted then the other one that I
> currently have.

This really shouldn't be decided on a per function basis. It's an issue on
the type level and should be fixed with the types themselves. The OP's
problem didn't even happen with a function. It happened with a built-in
operator.

Regardless, if you attempt to add keywords to the language at this point,
you will almost certainly lose. I would be _very_ surprised to see Walter or
Andrei go for it. Whether you think attributes are easy to read or not, they
don't eat up an identifier, and Walter and Andrei consider that to be very
important. AFAIK, they also don't consider attributes to be a readability
problem. So, even if trying to add some sort of implicit or explicit marker
to parameters made sense (and I really don't think that it does), I think
that Walter and Andrei have made it pretty clear that that sort of thing
would have to be an attribute and not a keyword.

And honestly, I think that any DIP trying to add general control over
implicit and explict conversions in the language has a _way_ lower chance of
being accepted than one that gets rid of implicit conversions between
character types and integer types. However, in the end, one does not depend
on the other or even really have much to do with the other. A DIP to fix the
implicit conversions between character types and integer types would be a
DIP to fix precisely that, whereas a DIP to mark parameters with implicit or
explicit would be about trying to control implicit or explicit conversions
in general and not about character or integer types specifically, so while
they might be tangentially related, they're really separate issues.

Given the recent DIP on copy constructors and the discussion there, it would
not surprise me to see a future DIP about adding @implicit to constructors
to allow for implicit construction, though I don't know how likely it is for
such a DIP to be accepted given that D's approach (outside of built-in types
anyway) has generally been to avoid implicit conversions to reduce the risk
of bugs, and when combined with alias this, things really start to get
interesting. But I would think that the chances of that getting accepted are
far greater than adding attributes to parameters (be they keywords or actual
attributes). Regardless, that's an issue of conversions in general, and not
just implicit conversions between character types and integer types, which
is really what the discussion is about fixing here, and that can be fixed
regardless of what happens with providing additional control over implicit
conversions in general.

- Jonathan M Davis





More information about the Digitalmars-d mailing list