[Issue 8143] Safe std.conv.to enum conversion

[d-bugmail at puremagic.com]

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


monarchdodra at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra at gmail.com


--- Comment #3 from monarchdodra at 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: -------