Welcome to This Week in D! Each week, we'll summarize what's been going on in the D community and write brief advice columns to help you get the most out of the D Programming Language.
The D Programming Language is a general purpose programming language that offers modern convenience, modeling power, and native efficiency with a familiar C-style syntax.
This Week in D has an RSS feed.
This Week in D is edited by Adam D. Ruppe. Contact me with any questions, comments, or contributions.
Beta D 2.071.1-b1 was released this week, a bug fix dmd release.
See more at the announce forum.
The case of autodecoding UTF in Phobos came up again, this time by Walter.
The current behavior in Phobos is that it considers string to be a range of dchar, a UTF-32 value, despite string being an array of char, a UTF-8 value. The original thought was to make D Unicode correct by default, so algorithms would work on non-ASCII input automatically.
The problem is that it it butchers performance in common cases, it confuses people over and over again, it complicates implementation of Phobos, and on top of it all, it doesn't actually lead to correct Unicode handling anyway!
The current autodecoding behavior almost universally seen as a mistake; the debate is almost unanimous against the behavior. However, it is not clear that we will actually change the behavior out of fear of breaking code that depends on the current rules.
Some also advocated for a new string type that is built on immutable(char) (currently string is just an alias for the array) but does not directly expose the array - instead, offering various ranges via getter functions. This would be a breaking change, but would offer a potential migration path and be an opportunity to educate users about Unicode.
This debate has happened before, at least once last year too, with similar results - agreement that the design is a mistake, but no action taken to change it. I'll be surprised if this time is different, though since Andrei now seems to agree it was a mistake - but is hesitant to break code by changing it - perhaps we will figure out a transition path so everybody wins.
Another thread - and another recurring issue - is floating point. The thread started optimistically, with Walter bringing up a problem Don Clugston mentioned in his DConf talk this year, and considering adding a warning. However, the thread proceeded into talking about other floating point precision issues, an argument that has happened before and Walter does not agree.
The precision issues, including consistency at runtime and CTFE and across machines, have a lot of proponents, though I don't think Walter understands their argument and until he does, there is no chance of change.
The comparison issue in the OP may get a warning though.
To learn more about D and what's happening in D: