http://d.puremagic.com/issues/show_bug.cgi?id=8143
monarchdo...@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monarchdo...@gmail.com --- Comment #3 from monarchdo...@gmail.com 2012-10-24 07:58:55 PDT --- (In reply to comment #2) > (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. I'd say there is nothing wrong with using floats as enums. It's rare because it's new (C++ only supported integral up to now). In C++, I've seen integral based enums used to index arrays which contained the actual payload (floats, strigns, others). Now we don't have to do this anymore. The *real* issue (IMO) is only when converting *back* from float to enum, which (IMO again), is plain too dangerous to realisticly assume we can support. I'd rather have float-to-enum always fail, personally. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------