On Mon, May 16, 2022 at 04:00:12AM +0000, cc via Digitalmars-d-learn wrote: > On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote: > > What are you stuck at? What was the most difficult features to > > understand? etc. > > > > To make it more meaningful, what is your experience with other > > languages? [...] > Immutability. Ended up having to do so many hundreds of casts to and > from immutable(whatever) the amount of mental strain greatly exceeded > whatever benefits the entire concept is supposed to offer.
If you find yourself having to cast to/from immutable, you're using it wrong. Most of my code doesn't have a single mention of immutable in it, and I don't care. It's there for when it's relevant, if it's not useful, don't use it. > Safety? Performance, in a future compiler version? I don't know > where it's at right now. What about performance? For anything performance-related, I don't even look at dmd, I use LDC all the way. DMD is only useful for fast compile-run-debug cycle, I don't even look at performance numbers for DMD-produced executables, it doesn't mean anything to me. > But you'd think I could do something like load some data from disk, > craft a few objects, mark them as immutable, and shove them in an > array or associative array without it being a nightmare, but it isn't. An explicit example would be nice. I write D programs that process input files all the time, including stuffing data into AAs and what-not, and it Just Works(tm). But not once did I bother with immutable (why should I?). The most I'd do is to mark something const (you might want to read up on the difference between immutable and const -- maybe that's why you had so much trouble), but even that I don't bother with most of the time. Const in D has limited utility beyond leaf-node data structures and modules, just let it be mutable and call it a day. > Or, having an otherwise mutable class with a member that references an > immutable class, but can change which immutable instance it's > referencing, without having to cast away the immutability of the thing > I'm trying to protect in the first place. So I just stopped doing it, > and simply rely on the "just don't make mistakes" practice to avoid > writing to things that shouldn't be written to now. Just make things private and use getters/setters to control access. Like I said, if you find yourself writing lots of casts when using immutable/const, you're probably doing it wrong. [...] > On another topic, the lack of a good "delete" keyword doing what one > would expect, when there's a perfectly good "new" without its matching > existential companion. This, and the ways around it, have already > been discussed to death though, but banging my head over trying to > force deterministic memory management into the GC-controlled D > universe did take its toll on a good year or two of productivity. Why would you want to force deterministic memory management onto GC-allocated objects? Just use malloc/free (or whatever else you fancy). Slap @nogc on main() and go from there, if that helps. IME, most programs don't actually need to care whether their memory is manually-managed or GC'd. Many of my programs use GC freely, except in inner loops where tigher control is needed, then I either preallocate or use malloc/free. But only where it actually makes a difference to performance. Outside of performance bottlenecks I don't bother with memory management, just let the GC do its job. T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy
