http://wiki.dlang.org/DIP52

Abstract:
Implicit conversion to and from other types are useful, and is to some extent covered by existing language features. Some cases are currently not covered, but could be worthy additions to the toolbox.

I've tried to figure out good ways to add some sorely-needed implicit conversions to the language, but I'm sure there are details that need to be ironed out. In other words - destroy!

--
  Simen

Simen Kjærås:

> http://wiki.dlang.org/DIP52

> However, given that this code compiles and works perfectly:
> 
> void baz() {
>    import std.typecons;
>    Tuple!(int, int) a;
>    Tuple!(int, "x", int, "y") b;
>    a = b; // Implicit conversion to less specialized type.
>    b = a; // Implicit conversion to more specialized type.

I think "b = a;" is an accepts-invalid bug.


> void foo(TaggedUnion!(float, string, int, MyStruct) arg) {}

Do you mean Algebraic?

Regarding the topic of implicit conversions, I propose to warn and then deprecate and then disallow the following two implicit casts, that only cause confusion, and are of no real utility:

enum Foo { A, B }
void main() {
    enum int i1 = 1;
    bool b1 = i1; // deprecate
    int i2 = Foo.A; // deprecate
}

Bye,
bearophile

On 2013-12-11 16:28, bearophile wrote:
> Simen Kjærås:
>
>> http://wiki.dlang.org/DIP52
>
>> However, given that this code compiles and works perfectly:
>>
>> void baz() {
>>    import std.typecons;
>>    Tuple!(int, int) a;
>>    Tuple!(int, "x", int, "y") b;
>>    a = b; // Implicit conversion to less specialized type.
>>    b = a; // Implicit conversion to more specialized type.
>
> I think "b = a;" is an accepts-invalid bug.

I partly agree. I want this to compile:

Tuple!(int, "x", int, "y") bar() {
    import std.typecons;
    Tuple!(int, int) a;
    return a;
}

And doing that without letting "b = a;" above compile seems counterintuitive and an unnecessary complexity.


>> void foo(TaggedUnion!(float, string, int, MyStruct) arg) {}
>
> Do you mean Algebraic?

Since a rewrite of Algebraic, supporting more features than the current version, is in progress, I chose to use a simple tagged union (which is what the current Algebraic is, I suppose).


> Regarding the topic of implicit conversions, I propose to warn and then
> deprecate and then disallow the following two implicit casts, that only
> cause confusion, and are of no real utility:
>
> enum Foo { A, B }
> void main() {
>      enum int i1 = 1;
>      bool b1 = i1; // deprecate
>      int i2 = Foo.A; // deprecate
> }

I agree, but feel that this is orthogonal to the DIP.

--
  Simen

On Wednesday, 11 December 2013 at 12:44:52 UTC, Simen Kjærås wrote:
> http://wiki.dlang.org/DIP52
>
> Abstract:
> Implicit conversion to and from other types are useful, and is to some extent covered by existing language features. Some cases are currently not covered, but could be worthy additions to the toolbox.
>
> I've tried to figure out good ways to add some sorely-needed implicit conversions to the language, but I'm sure there are details that need to be ironed out. In other words - destroy!
>
> --
>   Simen

In my opinion this DIP does not cover enough most important question for any DIP "what value does it bring that makes change worthy" or, in other words, "what problems is solves that can't be solved differently". Right now it is more like "this looks nice and you can do that" thing which does not sound convincing.

On Wednesday, 11 December 2013 at 12:44:52 UTC, Simen Kjærås wrote:
> http://wiki.dlang.org/DIP52
>
> Abstract:
> Implicit conversion to and from other types are useful, and is to some extent covered by existing language features. Some cases are currently not covered, but could be worthy additions to the toolbox.
>
> I've tried to figure out good ways to add some sorely-needed implicit conversions to the language, but I'm sure there are details that need to be ironed out. In other words - destroy!
>
> --
>   Simen

Implicit conversion has proven to be a really bad idea in C++. What make your solution superior to existing ones ?

On 2013-12-11 12:44:29 +0000, Simen Kjærås said:

> http://wiki.dlang.org/DIP52
> 
> Abstract:
> Implicit conversion to and from other types are useful, and is to some extent covered by existing language features. Some cases are currently not covered, but could be worthy additions to the toolbox.
> 
> I've tried to figure out good ways to add some sorely-needed implicit conversions to the language, but I'm sure there are details that need to be ironed out. In other words - destroy!

Although implicit conversions have some usecases, genrally they cause more damage then help.

One could use suggested mechanism for defining covariance/contravariance for user types, but it would be too adhoc and fragile.

On 2013-12-12 00:23, deadalnix wrote:
> On Wednesday, 11 December 2013 at 12:44:52 UTC, Simen Kjærås wrote:
>> http://wiki.dlang.org/DIP52
>>
>> Abstract:
>> Implicit conversion to and from other types are useful, and is to some
>> extent covered by existing language features. Some cases are currently
>> not covered, but could be worthy additions to the toolbox.
>>
>> I've tried to figure out good ways to add some sorely-needed implicit
>> conversions to the language, but I'm sure there are details that need
>> to be ironed out. In other words - destroy!
>>
>> --
>>   Simen
>
> Implicit conversion has proven to be a really bad idea in C++. What make
> your solution superior to existing ones ?

C++ has shown that having implicit conversion *by default* is a really bad idea. For instance, C# also has implicit conversion, but you have explicitly ask for it. If there's any critique of that anywhere (I expect there to be), I've been unable to find it.

And of course it'll be possible to abuse implicit conversions, just like one can abuse function names - this is the old example of 'What does add(1,2) return? Why, "empty string", of course. After connecting to a database.'. There's a simple solution to that problem - fire the person who wrote that code, fix the code, and move on.

Simply put, implicit conversions are not bad, nor good. They are exactly what you use them for.

--
  Simen

On Thursday, 12 December 2013 at 09:15:56 UTC, Simen Kjærås wrote:
> C++ has shown that having implicit conversion *by default* is a really bad idea. For instance, C# also has implicit conversion, but you have explicitly ask for it. If there's any critique of that anywhere (I expect there to be), I've been unable to find it.

...Explicitly implicit conversions?

On Thursday, 12 December 2013 at 11:42:23 UTC, Meta wrote:
> On Thursday, 12 December 2013 at 09:15:56 UTC, Simen Kjærås wrote:
>> C++ has shown that having implicit conversion *by default* is a really bad idea. For instance, C# also has implicit conversion, but you have explicitly ask for it. If there's any critique of that anywhere (I expect there to be), I've been unable to find it.
>
> ...Explicitly implicit conversions?

explicitly defined, implicitly applied.

On 12/12/13 10:15, Simen Kjærås wrote:
> Simply put, implicit conversions are not bad, nor good. They are exactly what
> you use them for.

Conversely, sometimes you want to be able to say, absolutely explicitly, "This function _must_ receive input of _this exact type_ with no implicit conversion allowed even if it normally would be."

You and I both encountered that with Don's BigInt code, and I found his solution to be elegant but fragile (inasmuch as it's easy for a later maintainer to misunderstand why it's the way it is and wrongly "correct" it).

So, you might want to factor that need also into your DIP.