Always false float comparisons

[Steven Schveighoffer via Digitalmars-d]

On 5/12/16 12:29 PM, Andrei Alexandrescu wrote:
> On 5/12/16 6:55 PM, Walter Bright wrote:
>> This reminds me of all the discussions around trying to hide the fact
>> that D strings are UTF-8 code units. The ultimate outcome of trying to
>> make it "make sense" was the utter disaster of autodecoding.
>
> I am as unclear about the problems of autodecoding as I am about the
> necessity to remove curl. Whenever I ask I hear some arguments that work
> well emotionally but are scant on reason and engineering. Maybe it's
> time to rehash them? I just did so about curl, no solid argument seemed
> to come together. I'd be curious of a crisp list of grievances about
> autodecoding. -- Andrei
>

Autodecoding, IMO, is not the problem. The problem is hijacking an array 
to mean something other than an array.

I ran into this the other day. In iopipe, I treat char[] buffers as 
actual buffers of code units. This makes sense, as I'm reading/writing 
text to buffers, and care very little about decoding.

I wanted to test my system's ability to handle random-access ranges, and 
I'm using isRandomAccessRange || isNarrowString to get around this.

As soon as I do chain(a, b) where a and b are narrow strings, this 
doesn't work, and I can't get it back.

See my exception in the unit test: 
https://github.com/schveiguy/iopipe/blob/master/source/iopipe/traits.d#L91

If you want to avoid auto-decoding, you have to be very cautious about 
using Phobos features.

-Steve