On Thu, 12 Aug 2010, dsimcha wrote: > This is from a discussion that originated on the Phobos mailing list, but I > thought I'd bring up the question of what should be done about const on the > newsgroup to see what others think: > > Despite its theoretical beauty, I find D's const/immutable system to be > utterly useless for all but the simplest use cases. I made a serious attempt > a while back to use it in a real multithreaded program. In hindsight it was > more trouble than it was worth, largely for three reasons: > > 1. It's difficult to create non-trivial immutable data structures, and often > impossible without relying on either unchecked casts or unnecessary copying. > > 2. Much generic code in Phobos (even things as simple as std.math.pow() > before I recently fixed it) behaves incorrectly when given const/immutable > data. This also applies to other libraries I use, including ones that I'm the > main author of, so I'm just as guilty of it as anyone. Given that noone, > including me, seems to be able to get const to interact well with generic > code, perhaps we need a language-level solution. > > 3. inout is currently so bug-ridden it's not even funny. (Though this is > clearly fixable long-term, once we get higher priority stuff off our plates.) > > It would have probably been better if this was brought to a head sooner, but > it's better late than never. Do others agree that D's const system is > difficult to impossible to use properly? Has anyone successfully used D's > const system in a non-trivial setting despite these limitations? If so, was > it more trouble than it was worth in hindsight? How can these limitations be > worked around and/or fixed?
For discussions like this, I think it's essential to distinguish between the language vs the runtime + core libraries. I recognize what matters is the end result usability, but examining the layers independently is really important. So, which are you talking about (could well be both)?