On Saturday, 27 July 2019 at 09:04:45 UTC, Mike Franklin wrote:
> (1) is all we need because we have enough metaprogramming facilities to implement (2) in the library.  What I'm thinking is that we create a more limited `alias this` that only does (1).  I'm thinking about syntax like this to distinguish it from the existing `alias this` feature.

Meh, that sounds bad. (1) doesn't achieve much without (2). And if you want your code to become a big ball of metaprogramming, you don't need alias this at all, you can replace it with DbI. You can replace most of the language with metaprogramming, and implement any type system there, it's basically lisp.

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

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.

On Saturday, 27 July 2019 at 18:50:16 UTC, Exil 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.

Any feature can be abused by a stubborn person. That is merely a case of bad coding practice rather then the feature itself.

On Sat, Jul 27, 2019 at 9:15 AM 12345swordy via Digitalmars-d <digitalmars-d@puremagic.com> 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

Right, the big difference is that implicit casting is opt-in. It would
only be used when it makes good sense, and not by accident.
I still think @implicit applied to normal copy constructors and/or
opCast is the best way though. That way the attribute can be extended
in the future if it makes sense to expand, specifically on copy
constructors where the function doesn't have a proper name.

On Sat, Jul 27, 2019 at 11:55 AM Exil via Digitalmars-d <digitalmars-d@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.

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

On Saturday, 27 July 2019 at 19:49:32 UTC, 12345swordy wrote:
> On Saturday, 27 July 2019 at 18:50:16 UTC, Exil 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.
>
> Any feature can be abused by a stubborn person. That is merely a case of bad coding practice rather then the feature itself.

Not every feature can be abused. This one is far more easily abused than others, and people will use it for "convenience" as I have seen them complain about before. It makes it harder to read code, to maintain code. It is the feature itself. If you need to use it in such a small amount of code so that it isn't abused, then it isn't really something you need.

On Saturday, 27 July 2019 at 16:12:35 UTC, 12345swordy wrote:

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

I salute you if you want to write a DIP, and I'll support in whatever way I can.  I might even be able to do the initial implementation, assuming I can figure it out.  That will help motivate the DIP.

Manu appears to prefer adding an `@implicit` attribute to the language for use on constructors and `opCast`.  I think that will also work.

I was leaning towards building on `alias this` simply because Walter has voiced opposition to implicit casting.  If we can get implicit casting approved, that would actually be my preference.

I think the DIP will have to build a very strong case including use cases and illustrating that it doesn't have the negative consequences of C++.  Then it might have a chance.  If the DIP fails, it will actually make any subsequent attempts just that much more difficult to justify, so it will need to be a damn good DIP.

Mike

On Sunday, 28 July 2019 at 00:45:54 UTC, Exil wrote:
> On Saturday, 27 July 2019 at 19:49:32 UTC, 12345swordy wrote:
>> On Saturday, 27 July 2019 at 18:50:16 UTC, Exil 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.
>>
>> Any feature can be abused by a stubborn person. That is merely a case of bad coding practice rather then the feature itself.
>
> Not every feature can be abused.

I recall my programming instructor scolded me for abusing basic functions.

> This one is far more easily abused than others, and people will use it for >"convenience" as I have seen them complain about before.

Examples?

> It makes it harder to read code, to maintain code.

Opinion.
 Also you can make the same argument regarding the goto statement.

> It is the feature itself.

The goto feature exist. You want to argue for deprecation for that feature?

> If you need to use it in such a small amount of code so that it isn't abused, then it isn't really something you need.

What language are you talking about here? Not every language implements implicit conversions the same way. For example C# rules for implicit conversions is much stricter then C++.

Alex