3 ms·
Yeah, I've read the document, and I would hope that most other people who proceeded to debate the topic did as well. I honestly don't think that it does a comme
by 4bpp 12y ago
Yeah, I've read the document, and I would hope that most other people who proceeded to debate the topic did as well. I honestly don't think that it does a commensurate job of presenting the case for it (and after reading many of the comments by proponents, I certainly am under the impression that there is a strong case for it; I just still think the case against it is stronger). A lot of the comments also show widespread uncertainty about the silent assumptions; I, for my part, am still at a loss as to why something like Cons(1, ~Cons(2, ~...)) is not an interesting or common use case according to some proponents (not necessarily restricting the question to cons-cell lists - the invoked universal utility of sharing tails, for instance, seems far less universal across the practical use cases of many other data structures).
- dbaupp 12y agoI can't quite tell from your last sentence if you realise this, but ~ doesn't provide sharing at all: ~T/Box<T> acts like a T in almost all ways, except it is guaranteed to be pointer sized (hence its use in recursive data structures, to allow them to exist without being infinite large). A pointer like Rc is required for sharing. Do note that the Cons cell construction becomes `Cons(1, box Cons(2, box ...))` which doesn't seem particularly bad.
- 4bpp 12y agoThanks for the clarification; I do realise this. The context in which the question arose was that several of the "for" arguments seem to state something to the effect of ~ being rare in code due to only occurring in type definitions.
- dbaupp 12y agoI believe that was just addressing the fact that the type `Box<T>` is more annoying than the type `~T`, since the `box expr` replacement for the `~expr` expression is relatively nice (admittedly I wasn't following the discussion in great detail).