http://d.puremagic.com/issues/show_bug.cgi?id=8143
--- 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: -------