--- Comment #2 from bearophile_h...@eml.cc 2012-10-23 18:59:14 PDT ---
(In reply to comment #1)
> This will fail internally if conv.to compares members via "==", because of
> floating point comparison semantics.
> So the question is, is this going to be a problem? If yes, should we use
> approxEqual for floating point comparisons?
By far the main purpose of enums is with integral values (ints, uint, chars,
etc), to be used to enumerate something or as bitfields. Using
float/double/real enums is supported in D, but it's not common.
Using approxEqual is suboptimal, using std.math.feqrel is better. but all
approximate floating point comparisons have their quirks and limits. Backing-in
one solution is not a good idea.
> Or maybe we should simply ban using
> std.conv on enums that have a floating point base type?
What about user-defined floating point types, or a double wrapped in a struct
with an alias this?
I think refusing conv on built-in floating point types is an acceptable
solution to avoid most troubles. Other cases like wrapped doubles are left at
the care of the programmer.
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------