On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis wrote:
>
> Whether an implicit cast or an explicit cast makes more sense depends entirely on what the code is doing, but either way, the conversion needs to be forced inside the function, or you end up with bugs. Far too often, when someone has a template constraint that checks an implicit conversion, the function doesn't actually force the conversion, and that can do anything from resulting in some instantiations not compiling to causing subtle bugs due to the argument being used without being converted. In general, it's actually best to avoid conversions entirely with generic code and force the caller to do the conversion if a conversion is appropriate.
>
> But ultimately, what works best depends on what the code is trying to do.
>
> - Jonathan M Davis

yeah it's hard to say much more without knowing what the code really wants to do..but presumably, you'd want to incorporate some contract programming in such a solution too, particulary given there's something potentially dodgy going on within such a function.

On Saturday, February 24, 2018 04:13:30 psychoticRabbit via Digitalmars-d- learn wrote:
> On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis
>
> wrote:
> > Whether an implicit cast or an explicit cast makes more sense depends entirely on what the code is doing, but either way, the conversion needs to be forced inside the function, or you end up with bugs. Far too often, when someone has a template constraint that checks an implicit conversion, the function doesn't actually force the conversion, and that can do anything from resulting in some instantiations not compiling to causing subtle bugs due to the argument being used without being converted. In general, it's actually best to avoid conversions entirely with generic code and force the caller to do the conversion if a conversion is appropriate.
> >
> > But ultimately, what works best depends on what the code is trying to do.
> >
> > - Jonathan M Davis
>
> yeah it's hard to say much more without knowing what the code really wants to do..but presumably, you'd want to incorporate some contract programming in such a solution too, particulary given there's something potentially dodgy going on within such a function.

Why is there anything dodgy going on and why would you need contracts? Contracts actually tend to go very badly with generic code, because whatever they assert has to be generic, and while that works sometimes, more often than not, it doesn't.

If you're testing for a conversion in a template constraint, simply forcing the conversion by assigning it to a variable of the target type (with an explicit cast if necessary) solves all of the problems related to testing for a conversion and then writing the code as if the argument were of the target type rather than a type that converted to the target type.

- Jonathan M Davis

On Sat, Feb 24, 2018 at 02:54:13AM +0000, Jonathan via Digitalmars-d-learn wrote:
> I am having trouble finding many useful explanations of using template constraints beyond basic usage.
> 
> I would like to have a template constrant to enforce that a type can be explicitly cast to another type:
> 
>     void (T)(T t)
>             if (cast(int) T)//force `cast(int) T` to be possible
>         {
>             // Yay I know `t` can be cast to an `int`!
>     }
> 
> Is this possible?

Yes:

	void (T)(T t)
	if (is(typeof(cast(int) T.init)))
	{
		...
	}

Explanation:

- is(X) generally means "is X a valid type?". It's the usual way of
  testing whether something is valid, because an invalid expression will
  have no type, and is(X) will return false for it.

- To make use of is(X), generally you want to use typeof to extract the
  type of some test expression.

- T.init is the usual D way of saying "give me an instance of type T",
  because every type has an .init.

- Putting it together, we have our test object T.init, and our test
  expression `cast(int) T.init`, extract the type of that using typeof,
  and use the is(...) operator to test whether that type exists.


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser

On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis wrote:
> Why is there anything dodgy going on and why would you need contracts? Contracts actually tend to go very badly with generic code, because whatever they assert has to be generic, and while that works sometimes, more often than not, it doesn't.
>
> - Jonathan M Davis

what if 3.3 is passed to the template, and it explicately casts it to an int.

To me, that would be dodgy - unless there was a contract, that I had accepted and agreed to, so that this not dodgy.

On Saturday, February 24, 2018 04:33:52 psychoticRabbit via Digitalmars-d- learn wrote:
> On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis
>
> wrote:
> > Why is there anything dodgy going on and why would you need contracts? Contracts actually tend to go very badly with generic code, because whatever they assert has to be generic, and while that works sometimes, more often than not, it doesn't.
> >
> > - Jonathan M Davis
>
> what if 3.3 is passed to the template, and it explicately casts it to an int.
>
> To me, that would be dodgy

It could be exactly how the function is intended to work, since that's how casting to int works for float. And there's nothing dodgy about a cast from float to int losing the part of the value to the right of the decimal place. That's the expected behavior.

> - unless there was a contract, that I
> had accepted and agreed to, so that this not dodgy.

All contracts are are assertions. That's it. There's nothing special about them. An in contract is used to verify that the function is given valid data, but there really isn't any accepting or agreeing to a contract. Rather, it's something that blows up in your face if you give it bad data so that you can catch bugs. Presumably, the documentation gives the requirements for the function if it has them, and then an in contract can be used to verify that the arguments don't violate those requirements, but all it is is a tool for catching bugs.

And there isn't necesarily anything buggy about casting 3.3 to an int. That depends entirely on what the code is supposed to be doing.

Now, by having the function simply accept int you avoid the entire question, because then it's up to the caller to decide how they go about converting to int, and I'd argue that that's better in general, but there are times when casting within the function may make more sense.

- Jonathan M Davis

On Saturday, 24 February 2018 at 03:04:07 UTC, Adam D. Ruppe wrote:
> On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
>> I am having trouble finding many useful explanations of using template constraints beyond basic usage.
>
> The constraint is just like static if as to what it allows inside, so you can check almost anything in there.
>
> Like for the cast, you might do
>
> void name(T)(T t) if(__traits(compiles, cast(int) t) {}
>
> just seeing it the cast compiles.
>
> You might also do
>
> if(is(T : int))
>
> which asks if T is implicitly convertible to int. But since you want explicit cast, the compiles is prolly the way to go.
>
> is: https://dlang.org/spec/expression.html#IsExpression
> compiles: https://dlang.org/spec/traits.html#compiles

Thanks, this was just what I needed to know.