The year is 2019

[Exil]

On Saturday, 27 July 2019 at 22:36:23 UTC, Manu wrote:
> 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
>   }

Not sure what you mean by this example. There already is implicit 
conversion when you declare variables.

If "thing" can be converted to type U, then you don't need a 
special case. It just means the following:

     takes_type_u( U(thing) ); // no special case

The only difference implicit conversion would make in this case 
is this:

     takes_type_u( thing ); // do we convert here or not?

I get what you mean with generics though. It's why I don't use 
"const" why I don't use pointers and such. There are a lot of it 
already where you need special `static if`s to handle generic 
code. You can't even write generic code that works for @nogc and 
GC. Yes it should be fixed but I don't see how it is easily 
fixable.

Maybe it's just not the best example, I kind of know what you are 
trying to say but I can't think of a better example right now.

> 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.

I think it'd be even worse with meta programming. Now not only do 
you not know what type you may have, case it can be any type. You 
can also possibly convert it to any other type with implicit 
conversion. This would make it even more difficult to try to read 
and understand what is going on with implicit conversions. It 
could make it more powerful, and have the code be simpler. But 
overall it makes maintainability a pain, especially so since it 
makes the code look simpler, when in reality it is actually far 
more complicated.