implicit conversion

Meta via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Aug 12 06:17:37 PDT 2014


On Tuesday, 12 August 2014 at 06:37:45 UTC, Jonathan M Davis via 
Digitalmars-d-learn wrote:
> The problem is that isNaN is now templatized, and its 
> constraint uses
> isFloatingPoint, which requires that the type _be_ a floating 
> point type, not
> that it implicitly convert to one. So, as it stands, isNAN 
> cannot work with
> any type which implicitly converts to a floating point value. 
> Either it will
> have to be instantiated with the floating point type - e.g. 
> isNaN!float(s) -
> or you're going to have to explicitly cast s to a floating 
> point type.
>
> You can open a bug report - https://issues.dlang.org - and mark 
> it as a
> regression, and it might get changed, but the reality of the 
> matter is that
> templates don't tend to play well with implicit conversions. 
> It's _far_ too
> easy to allow something in due to an implicit conversion and 
> then have it not
> actually work, because the value is never actually converted. 
> In general, I
> would strongly advise against attempting to give types implicit 
> conversions
> precisely because they tend to not play nicely with templates.
>
> - Jonathan M Davis

I think this should be considered a bug. A type with alias this 
should work in all cases that the aliased type would. If the 
function fails to be instantiated with S!float, then it should be 
forwarded to the S's val member.


More information about the Digitalmars-d-learn mailing list