The year is 2019

Manu turkeyman at gmail.com
Sat Jul 27 22:36:23 UTC 2019


On Sat, Jul 27, 2019 at 11:55 AM Exil via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Saturday, 27 July 2019 at 16:12:35 UTC, 12345swordy wrote:
> > On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin wrote:
> >
> >> I would be perfectly happy with `opImiplicitCast` or some way
> >> to have implicit constructors.  But Walter has already voiced
> >> his disapproval of that (See the comments in
> >> https://github.com/dlang/dmd/pull/10161 for the
> >> disappointment), so our choices are getting slim.  I'm trying
> >> to find something he would be willing to approve. If you have
> >> any ideas, I'm all ears.
> >>
> >> Mike
> >
> > We shouldn't let Walter disapproval effect us. If we think it a
> > really good idea then we should pursuit it.
> >
> > Walter thinks the opImplicitCast that we are proposing will be
> > the same thing as C++. It isn't. C++ genius "idea" is to have
> > implicit conversions opt-out rather then opt-in.
> >
> > -Alex
>
> I don't agree. C++ strings are a good source of how it can be
> misused. I'm glad QString doesn't have implicit conversion with
> std::string. I remember reading a comment on a
> QString::fromStdString() call that was something along the lines
> of, "shitty QString doesn't support implicit conversion to
> std::string". I can only imagine how difficult it would be to
> track down all the implicit conversions to and from QString if it
> was an implicit conversion. And for whoever wrote that comment
> cause they didn't want to write a few extra characters.
> Ultimately it doesn't add functionality, it just reduces the
> amount of code you have to write by a small amount in some places
> and ultimately it makes your code less readable because of the
> hidden conversions. I don't think it's worth the price to pay.

You can only make the argument if you basically ignore meta-programming.
This is a constant fight in D; where people seem to love extra
special-case explicit junk in some cases, but the trouble is in any
generic code, you then need to start doing:

  static if (is(T == SpecialCaseThing)
  {
    U x = special_case_conversion(thing);
  }
  else
  {
    U x = thing; // direct or implicit conversion
  }

And that kind of thing is cancer to generic code, and having the power
to specify some implicit conversions in code that are relevant to your
program could reduce a whole lot of code like that.
Generic code needs to be as short and brief as possible to remain easy
to reason about, but then arguments like your one above cause exactly
the kind of friction we should avoid.

Now, you might make an argument about meta-programming at all; but
meta-programming is D's single biggest undeniable advantage and
success story over every other language, and frankly, if you're not
behind meta-programming, you're in the wrong place.
So I take that as guiding principle, and from there, I will always
argue in favour of uniformity of expression, rather than requiring
special-case manual shit on a case-by-case basis which is practically
incompatible with meta-programming.

I think implicit conversions are EXTREMELY enabling for a lot of cases
of meta-programming in D, and I also feel much more comfortable with
the idea that they are opt-in rather than opt-out as in C++. I think
that's the right balance.


More information about the Digitalmars-d mailing list