[Issue 9286] std.conv.parse fails to compile with Nullable

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9286



--- Comment #8 from jens.k.mueller at gmx.de 2013-01-09 04:07:20 PST ---
(In reply to comment #7)
> > Why is it impossible to make isIntegral work for user-defined types in the 
> > same way as e.g. isInputRange works?
> > They do have an API. Just to mention some you use +, -, *, / etc. You just 
> > need to fix this set.
> 
> Because those operations aren't unique to integral types. They're not even
> necessarily unique to _numeric_ types. Input ranges have fairly a unique API,
> so you can test for it, but integral types don't have an API that's even
> vaguely unique.

I believe the set of operations is unique. But I would need to try it out. Do
you happen to know of an example that supports the set of integral oprations
yet is no integral?

> > Can't do this as this happens inside getopt. I pass getopt a Nullable and
> > later check whether it was actually set by getopt.
> 
> Well, with getopt's design, you're pretty much stuck either using uint (and
> assuming that 0 means that nothing was set or just use 0 as the default for
> whatever you're doing), or you have to take the string and do what you want to
> yourself. It's just not designed to distinguish between an option not being set
> and it being set to the default. I suppose as an alternative, you could use a
> floating point type and if it's not NaN, test to make sure that the result is
> an integral.
> 
> I suppose that a possible solution to the design issue with getopt would be to
> make it special-case Nullable so that you'd get the behavior that you're
> looking for.

Yah. Same here. I will look for a way to fix this in my code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------