On Thursday, 12 December 2013 at 14:47:17 UTC, Joseph Rushton Wakeling wrote:
> 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 can write something like:

void acceptMyType(T)(T arg) if(is(T == MyType))
{
...
}

Yes, this way is complex, but this situation is rare and we can	put up with it.

IMO, implicit conversion possibility for user types should be in a language, but this possibility should seems unattractive for user. User should know that he can use this ability only if he sure that he want it.

May be opImplicitCastFrom method is a good solution, but it should be a static method whick accept T arg and returns UserType object.

struct UserType
{
     int a;
     static UserType opImplicitCastFrom(int a){return UserType(x);}
}

UserType o = 5; //should be converted to UserType o = UserType.opImplicitCastFrom(5);
implicit calling of constructor should be deprecated in this case.
UserType o2 = UserType (5); //use constructor

void foo(UserType x);
foo(5); // => foo(UserType.opImplicitCastFrom(5));

opImplicitCastFrom shouldn't be a non-static method (like opAssign), because we would need to call default constructor before opImplicitCastFrom call in this case, and if class doesn't define default constructor we wouldn't able to provide implicit conversion.

Another suggestion: add special form of alias this construction:

struct UserType
{
     int a;
     alias myImplicitCast this;
     static UserType myImplicitCast(int a){return UserType(x);}
}

If alias this argument is a static function which accepts one parameter and returns typeof(this), it can be used for implicit conversion.

On 13/12/13 01:23, IgorStepanov wrote:
> You can write something like:
>
> void acceptMyType(T)(T arg) if(is(T == MyType))
> {
> ...
> }
>
> Yes, this way is complex, but this situation is rare and we can put up with it.

Yes, that's exactly the method I was thinking of.  I really found it very beautiful when I saw it inside std.bigint and realized what it was meant to do, but I think it's _very_ prone to being accidentally "corrected" on the assumption that it's meant to be is(T : MyType).

On Friday, 13 December 2013 at 10:39:41 UTC, Joseph Rushton Wakeling wrote:
> On 13/12/13 01:23, IgorStepanov wrote:
>> You can write something like:
>>
>> void acceptMyType(T)(T arg) if(is(T == MyType))
>> {
>> ...
>> }
>>
>> Yes, this way is complex, but this situation is rare and we can put up with it.
>
> Yes, that's exactly the method I was thinking of.  I really found it very beautiful when I saw it inside std.bigint and realized what it was meant to do, but I think it's _very_ prone to being accidentally "corrected" on the assumption that it's meant to be is(T : MyType).

a quick "//no implicit conversion allowed" is surely adequate here. At the very least it would make someone think twice before breaking it.

On Wednesday, 11 December 2013 at 15:28:51 UTC, 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.

It's not. It works because of the user-defined Tuple.opAssign.

On 2013-12-13 01:23, IgorStepanov wrote:
> IMO, implicit conversion possibility for user types should be in a
> language, but this possibility should seems unattractive for user. User
> should know that he can use this ability only if he sure that he want it.

Absolutely.


> May be opImplicitCastFrom method is a good solution, but it should be a
> static method whick accept T arg and returns UserType object.

That was the plan. Updated the DIP to specify this.

--
  Simen