http://d.puremagic.com/issues/show_bug.cgi?id=9286
--- Comment #8 from [email protected] 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: -------
