RFC: Remove ~ in favor of box and Box
#59
Conversation
|
This will probably need DST to land completely before entirely removing |
|
This also may interact poorly with the widely-used |
|
We could still start replacing it before removing it completely. |
|
A few questions:
I think there was a possibility of having |
|
@thehydroimpulse to the best of my knowledge |
| # Alternatives | ||
|
|
||
| The other possible design here is to keep `~T` as sugar. The impact of doing this would be that a common pattern would be terser, but I would like to not do this for the reasons stated in "Motivation" above. | ||
|
|
There was a problem hiding this comment.
+1 for this. I'm all for removing ~EXPR, but I think ~T is a really nice sugar. Having smart pointers as sigils rather than generics makes reading (and writing) Rust much nicer than the equivalent C++.
To address the motivating points: I think Box is to generic a word to be self-documenting, it doesn't tell us anything about how the type behaves or how it is different from &, *, Rc, etc.
Having more than one way to do something is a noble goal, but we have to balance that against convenience. In this case there is a clear way to decide which to use (whether you are using an allocator or not) and we could even enforce that with a lint.
I'm not sure about the 'blindly adding sigils' thing. It kind of seems like a reasonable argument, but do we know people don't do it? If they see Box<...> everywhere in the code, are they likely to do the same with Box<...>?
There was a problem hiding this comment.
Having smart pointers as sigils rather than generics makes reading (and writing) Rust much nicer than the equivalent C++.
That's quite subjective, as I think it's far easier to read code when it's using normal syntax instead of a special case in the language. Python is a language often referred to as easy to read, and that's said because it avoids sigils, braces and other line noise. Unique pointers are rarely used, and when they are they're rarely spelled out due to type inference. There are far more common patterns, so I don't understand why this one would deserve syntax hard-wired into the language. Even a module like collections::treemap based on unique pointers barely uses the sigil.
it doesn't tell us anything about how the type behaves or how it is different from &, *, Rc, etc.
It behaves as a normal owned type with a destructor, just like a Vec<T> or a HashMap<K, V>. Rust types are expected to have unique ownership by default so Box<T> is really no less informative than TreeSet<T>. Types like Rc and Arc are very rare exceptions.
Having more than one way to do something is a noble goal, but we have to balance that against convenience. In this case there is a clear way to decide which to use (whether you are using an allocator or not) and we could even enforce that with a lint.
It doesn't make sense to add conveniences for things that are rarely used and meant to be discouraged. Vectors and strings are covered by Vec<T> and StrBuf so the remaining use cases for this are recursive data structures where you really just write out the type a single time in the type definition, owned trait objects (which are almost always avoided in favour of generics) and extremely rare circumstances where you want to hoist something large off the stack rather than just borrowing (I can't find a single case in the Rust codebase - it's just used in recursive data structures to make them smaller).
I'm not sure about the 'blindly adding sigils' thing. It kind of seems like a reasonable argument, but do we know people don't do it?
Few people learning Rust understand that unique pointers are not special and could be implemented in a library. It's clearly not something that's going to get across to newcomers. I've explained this thousands of times to people in #rust... it would be nice if the language just made some effort to avoid obscure, confusing syntax in the first place. The pointer sigils are often brought up as something that makes Rust hard to approach, and the only ones commonly used are & and &mut.
There was a problem hiding this comment.
I agree that sigils vs generics is subjective. I don't think Python is a good argument in favour of generics though, as you say it avoids braces (and types, never mind generic types) and the problem I have with generic types is when you get a bunch of them nesting up and it all becomes hard to parse.
I would be in favour of making other more common patterns more convenient too. The difference is here we are talking about removing a convenience rather than adding one.
My point about them being self-explanatory is that you still have to go to the docs to find out what Box means, just like Vec or TreeSet. So this is not an advantage over ~. Box doesn't tell me it is heap allocated, is implemented as a pointer, or is unique. I disagree that Rust types are expected to be unique by default - & is the most common (non-value) type and is not unique, likewise Rc, etc. Only ~ and values are unique, and I believe most programmers with a systems background will have a mental divide between pointer types and value types.
I prefer ~[T] to Vec<T> for the same (admittedly subjective) readability reasons. I'm not sure we should be discouraging use of unique pointers. They are the easiest/best way to allocate something on the heap and that seems kind of popular in other languages. I don't think we understand the cost/benefits of idiomatic Rust programming well enough at this stage to be so bold about what programmers should be doing. In particular, the Rust code base is a compiler implementation, and compilers are a fairly unique kind of programming. We should not generalise from rustc to all programming in Rust.
I don't think it is important what can or can't be implemented in a library or for people to understand how 'special' something is. It is important that people understand the language concepts and how to use them.
I agree we should avoid obscure and confusing syntax, but I don't agree that pointer sigils are. After all, pointers are usually denoted by sigils, particularly in C/C++. Currently we only have one more pointer sigil than C++, so I don't think that criticism of Rust is valid anymore (and I haven't heard it as much recently).
There was a problem hiding this comment.
I agree that sigils vs generics is subjective. I don't think Python is a good argument in favour of generics though, as you say it avoids braces (and types, never mind generic types) and the problem I have with generic types is when you get a bunch of them nesting up and it all becomes hard to parse.
It uses and instead of &&, or instead of ||, list instead of [] and so on. Most people find it far easier to read and search for these than the sigil alternatives. The avoidance of more than one way to do the same thing (like including both ~T and Box<T>) is another reason why people find Python easy to read. There's a consistent style for writing it, so programmers can read each other's code without adjusting to another style.
I would be in favour of making other more common patterns more convenient too. The difference is here we are talking about removing a convenience rather than adding one.
This isn't a common pattern though. The mention of Box<T> occurs a single time for each child in the type definition for a recursive data structure and isn't written out at all in the code. There aren't other common use cases. The type definitions are almost always quite short and there's no need to trim off characters.
My point about them being self-explanatory is that you still have to go to the docs to find out what Box means, just like Vec or TreeSet. So this is not an advantage over ~.
You can easily search for "rust box" on a search engine, and it's a lot harder to search for a sigil not even found on some keyboard layouts. The use of tilde feels a lot like including Unicode mathematical symbols in the language syntax to a lot of programmers. https://en.wikipedia.org/wiki/Tilde#Keyboards
Box doesn't tell me it is heap allocated, is implemented as a pointer, or is unique. I disagree that Rust types are expected to be unique by default - & is the most common (non-value) type and is not unique, likewise Rc, etc. Only ~ and values are unique, and I believe most programmers with a systems background will have a mental divide between pointer types and value types.
The term box in Rust means a heap allocation, so it does tell you that. The HashSet<T> or int type doesn't tell you that it's owned in the name, so I'm not sure why you're applying this logic here but ignoring it for every other type. Unique pointers are certainly a value type, just like Vec<T> and HashMap<K, V>. All 3 of these types contain an internal pointer to their data, but have normal value semantics.
I prefer ~[T] to Vec for the same (admittedly subjective) readability reasons. I'm not sure we should be discouraging use of unique pointers. They are the easiest/best way to allocate something on the heap and that seems kind of popular in other languages. I don't think we understand the cost/benefits of idiomatic Rust programming well enough at this stage to be so bold about what programmers should be doing. In particular, the Rust code base is a compiler implementation, and compilers are a fairly unique kind of programming. We should not generalise from rustc to all programming in Rust.
I think there's little doubt that people find the sigil noise hard to understand. It doesn't exist in other languages, and it's not even familiar to C++ programmers. If Mozilla wants to start paying me for for the hours of time I spend explaining this confusing syntax to people on #rust then I'll stop complaining...
As a compiler implementation, rustc has far more recursive data structures than is the norm elsewhere. I think it's a great place to look to find out if unique pointers are commonly used. Since it's written by people who know the language, it's also a great place to look if you want to determine how frequently unique pointers end up misused due to the overly sweet syntax.
They are the easiest/best way to allocate something on the heap and that seems kind of popular in other languages.
The normal way to do a heap allocation is by using a container performing a heap allocation internally. It's not common to be doing it manually and it indicates that the code needs refactoring or serious reconsideration.
There was a problem hiding this comment.
Box doesn't tell me it is heap allocated
really? Hm.
They are the easiest/best way to allocate something on the heap and that seems kind of popular in other languages.
Right, but Rust isn't other languages: you should prefer stack allocation as much as possible. Other languages prefer heap allocation because GC.
There was a problem hiding this comment.
@thestinger that box means heap in Rust doesn't help newcomers understand it. They need to find that out from the docs or elsewhere, so it is not self-explanatory.
I argue that pointers (including smart pointers) are different from data structures because they are a pointer, rather than containing a pointer.
I'm not saying ~ is easy to understand, I'm saying it is not much more difficult than Box<T> to understand. C++ uses * and & as pointer sigils and we add another one. What is more difficult to explain is the semantics of ~ and that remains unchanged with Box.
rustc may well have more recursive data structures than other compilers. But it still conforms to well known patterns of compiler implementation that are not often found elsewhere. Designing language which are ideal for writing their own bootstrap compiler and awkward for other tasks is a well-known phenomenon and we should be careful to avoid it (which I think we are, but we need to continue to be careful).
Your point about allocating only in collections to the point of refactoring is extreme. Pretty much any C or C++ code base is full of new/mallocs.
There was a problem hiding this comment.
I agree with @nick29581. I'm ok with removing ~expr, but I would really like to see ~T stay.
There was a problem hiding this comment.
boxonly means heap allocating in Rust and we're are talking about learning the language.
Not so, "boxing" is the term of art for indirect heap-allocated structures in FP languages implementations and — although the meaning is somewhat broader[0] — in OO languages with a visible distinction between "object" and "primitive" types such as Java and C#.
[0] it includes both heap-allocation and wrapping in a full-fledged object
There was a problem hiding this comment.
@nick29581: It's not obvious that it's simply a completely normal type and not extra language complexity to newcomers. With the Box<T> syntax, it's clearly a normal type name and not some kind of modifier like mut. Many people are confused by the syntax and see it as an ownership operator, rather than a smart pointer type. There's a lot of precedence in other languages for our usage of *T and &T, but ~T is right out of left field.
I'm not saying ~ is easy to understand, I'm saying it is not much more difficult than Box to understand. C++ uses * and & as pointer sigils and we add another one. What is more difficult to explain is the semantics of ~ and that remains unchanged with Box.
The semantics are not hard to explain, because they're the same semantics used by other types like Vec<T>. The tutorial already does a good job explaining ownership and move semantics. The questions from people reading the tutorial are almost always related to confusion about the owned pointer syntax. It will be a bit better without ~str and ~[T], but it's still going to be interpreted as some magical modifier rather than a type.
Your point about allocating only in collections to the point of refactoring is extreme. Pretty much any C or C++ code base is full of new/mallocs.
Modern C++ code does not call malloc or new any more frequently than you do in Rust. It uses std::vector as the main memory allocation tool, with std::unique_ptr being used to build recursive containers or make use of virtual functions.
There was a problem hiding this comment.
what was impressive originally was not just ~T but how it had been combined with ~[]; between those characters it had eliminated the 'vocabulary' of unique_ptr, vector, and make_unique .. of course now that ~[T] isn't 'the most widely used collection' ~ appears less. r.e. 'learning the language' one thing I had really liked is this had given Rust an almost json like quality of common data structures that could be pretty-printed looking like the actual language syntax for creating them. As a C++ programmer i'd looked enviously at the way languages with decent repls worked on this front, where you can test snippets interactively. I saw an intriguing function search tool for clojure where you specify some input and some output, and it empirically searches for functions that actually do that transformation. Of course this refers to 'some blessed types' and I certainly agree with the goal of generality/versatility.. making user defined types as powerful as anything in the language.. but nonetheless that was extremely appealing.. a big part of the elegance & fresh feel of rust. I know being interpreted isn't a rust goal , but a language as powerful as C++ with a useful interpretable subset would have been rather interesting
|
well moving isn't disasterous, and I can see the benefits of generality. But are you underestimating the value of sugar. What is rust, but C++14 with a static analyzer? The fact it had compact syntax for the types used most of the time (a std::vector alike being ~[T] , unique_ptr being ~T ) was actually a big draw. Between ()tuples ~ [] .. you could write a lot of useful datastructures without much noise getting in the way of your own symbols. Still the generality is good. I personally want 32bit indexed vectors on a 64bit machine (for 8gb,16gb targets), and relative/compresed pointers (in arenas/precompiled object graphs) etc. I know i wouldn't have been able to get that with ~[T], ~T. Whats going to happen with move semantics, will there be generalized mechanisms for that |
|
Sugar makes sense for things that are common. Unique pointers are anything but common, because recursive data structure definitions are few and far in between. The sigil is only used to define the data structure itself. The code implementing the data structure never actually uses the sigil due to type inference. There will be a single place where new nodes are created, covered by the
There's already nothing special about unique pointers in regards to move semantics. |
|
I think that the success of removing Perhaps we could find examples of recently-written Rust code (the Ludum Dare entries, perhaps?) and count the frequency of unique pointers for some hard data. |
|
" because recursive data structure definitions are few and far in between." they're very common for me. a lot of the code i write is basically "build a recursive datastructure, then work on that to produce something simpler". Whats the compiler itself going to use, isn't it all @ at the minute, set to change. |
So you have to write the sigil a single time in the type definition, and those lines are almost always incredibly short. You never have to write it in the code implementing the data structure. |
|
" and those lines are almost always incredibly short.", yeah with nice sugar, they're pleasingly short :) |
|
I thought I was in favor of this, but being able to construct algebraic data types requiring boxing with minimal syntactic noise is an extremely nice property to have. Eg, let list = Cons(1, ~Cons(2, ~Cons(3, ~Nil))); This immediately shows off the power of the language for any lisp, ML, haskell programmer. |
|
@julian1: That's not a useful data structure. It's also far noisier than it would be if you factored out the code into functions, where you're only going to need the |
|
ok well, i can setup the text editor shortcut and keyboard macro to write a symbol. Option<~T> could be The nice thing about the sigil isn't just that its compact, its the lack of nesting; the unpopularity of lisp should show the significance 'not being nested' can have. Its also the reason (i think) for the popularity of OOP - the a.foo(b) calling syntax is less nested than foo(a,b) when you combine calls. I had a suggestion which might sound crazy, to use @ like haskells' $ as a tool to fight nesting. imagine if |
|
@bstrie: There's no need for statistics and intuition when we already know when these are useful (recursive data structures, owned trait objects). I can't find a single valid use outside of a recursive data structure or for an owned trait object in the upstream Rust code. There's plenty of code misusing unique pointers and that's an argument for removing the sugar, not keeping it. |
|
@thestinger of course it's useful to be able to cleanly construct recursive data structures in code, without having to write a bunch of supporting functions. Otherwise, I agree that other cases are weak, and that they are very prone to misuse. One point - if type constructors were functions (like Haskell) , then could this sugar be handled with macros? |
I can't really see why the standard library would include a bunch of type aliases for rarely used patterns.
The language is designed as a coherent whole and the features are intended to be orthogonal with each other. It makes little sense to provide multiple ways of doing the same thing because a noisy minority dislikes the regular way of doing it. If you have a problem with Rust's generics syntax, then please raise that as an issue. Adding an entirely different generics syntax to live alongside it seems like a really bad way of dealing with it... Many keyboard layouts do not have a tilde key so trying to argue from the perspective of ease of writing code is not at all sensible. It's a very anglocentric thing to assume... and we often hear people complaining that they don't have this key on #rust. |
|
"If you have a problem with Rust's generics syntax, then please raise that as an issue" ... The generics syntax is not a problem... when complemented by sugar for common types. Complex types get harder to read , the more you compose. ~T was very easy to compose (eg per Option<~T>).. that was the value. wihtout it we'll need to start creating more vocabulary |
|
👍 from me. Some people have got the misconception that If |
|
@julian1: I have a hard time seeing |
|
been on uk keyboards and mac keyboards, ~ is fine :) |
|
@dobkeratops: I linked https://en.wikipedia.org/wiki/Tilde#Keyboards above. We're had plenty of complaints about this on #rust and it's not something trivial to brush aside. The claim that it's easier to type is simply not true... most people do not find it easier even on a US keyboard, because you need to press a modifier and reach for the upper left corner. It's worse when you don't have the key at all, and you need to use a search engine to figure out how to make one. |
|
Yeah, I think the fact that |
|
If |
|
Just to give my two cents: I think it's a much better idea to remove the sugar, start using this, then reconsider the sugar. If Rust is serious about being a systems language, then we need to collectively get over this obsession with sugar we seem to have developed. Sugar is, by and large, not a good thing. More often than not it causes programmers to use inflexible patterns, resulting in duplicated effort because using |
|
So, since this is a major language change, I'd like to weigh in here too 😸 I'm a huge fan of the sugar that ~ provides to the language - as @dobkeratops mentioned above, it's nice to avoid the nesting that could potentially be caused by Also, some things to consider:
My 2¢ 😃 |
|
yes, tree structures are very common in graphics. scene graphs, hierarchies. |
This goes against adding orthogonal features and enforcing consistency in the language. Rust has made a lot of effort to remove countless features like structural records to simplify the language. Memory allocation is something Rust intends to discourage, and it's not supposed to be common. There's only going to be a single function creating nodes in a recursive data structure implementation.
Instead of making a straw man argument, how about responding to what I actually wrote? Recursive data structure type definitions are few and far between. The |
|
@dobkeratops: Rust isn't trying to be the second coming of C++. It is not intended to have every possible feature included in the language and it doesn't try to permit more than one style for writing the same code. It's definitely an opinionated language, while C++ is quite the opposite. The features in the language have been carefully chosen to be as orthogonal as possible. Many neat but mostly redundant features like structural records and export lists were removed. There's an old list of some here. It follows the Python philosophy of providing only one way to do something whenever it can do it without hurting other goals like performance. |
|
👍 from me! Folks already covered pretty much all my thoughts on this already!
Big +1 here! 🍰 |
I really don't think it would work. No C++ in existence would pass the borrow check. You'd have to basically rewrite the code, at which point there's little point to using C++—you might as well use a different language (which you've essentially created anyway). The closest thing was Cyclone, which used garbage collection everywhere. It required a fair number of annotations to make work. |
existing source bases which have users depending on them, and mature tools, and programmers with familiarity; you'd do rolling refactors, code would get progressively cleaned up. And people still get their photoshop, unreal engine, whatever. The tool would asserting where the checks should be in places where rust uses match, and so on. C++ has lambdas now which I think make safe patterns easier (like the rust iterators). If i've understood correctly, proponents of the modern c++ style basically treat * as unsafe, and say everything should be wrapped in smart pointers. The direction you're moving in is very, very close. #define Box unique_ptr :) |
|
@dobkeratops I claim that this sub-discussion (of whether one can, as you put it, construct "a 1:1 correspondence to things dobkeratops understood in C++", to the extent of actually building a concrete analysis tool) has taken the comment thread drastically off-course from the content of this RFC. In my view, the whole point of having the RFC repository has been to try to allow for more focused discussions. If we let these threads spin off in arbitrary directions, the process will not be sustainable. Therefore, I politely request that the participants in that sub-discussion migrate the discussion of such an analysis to a different forum, such as a reddit thread, and try to refrain from continuing it on this pull request comment thread. That, or I guess try to ensure that every comment you add actually draws some explicit connection to this RFC. added Postscript: Of course the last line of the previous comment, "#define Box unique_ptr", could be interpreted as the explicit connection to this RFC that I requested. But I do not interpret it as such. |
|
I also like this RFC. Initially, when learning the language, it was peppered with tilde symbols, but as I have continued, they use has been minimized to such a degree that I wouldn't mind them going away completely. One of rust-lang's strengths is that it is obvious what you pay for. That a single symbol may induce calls to allocation functions is counter to that intuition. I would actually go even further, not using box() to both allocate and create the box, but to use a new() function to do it. |
|
@thestinger You have a point, Daniel. |
|
+1 for removing from the language and re-adding it later if it is deemed wanted. I think a problem is that people think |
now, strangely I actually react less badly to this if rust was to use a "new" keyword rather than "box" for this purpose. then changing to 'box'/Box... no benefit, a step backwards. seems like a pointless rename of a concept. but if it was 'new', I'm already used to reading that for allocation... I can keep more coherence in my head when alternating between C++ and Rust. that might go against rusts' convention of 'new' for constructors? but if you changed those to '::init' or something, you'd put Rust into a state where its slightly more intuitive for users of other languages, and easier to translate API's directly (e.g. if one wants to make bindings to Rust code in C++..) |
|
@dobkeratops , for historical context, please see this extensive mailing list thread: http://thread.gmane.org/gmane.comp.lang.rust.devel/6926 Originally, the |
|
To clarify, no - I didn't suggest 'new' as a keyword. To construct an Rc, you use: let x = Rc::new(5); I am suggesting that boxed values should use: let x = Uniq::new(5); Sidenote: As a game developer, I really hate the fact that words like 'box' and 'crate' are reserved. |
|
That will not work because of the evaluation order. Please read the thread On Thursday, May 1, 2014, engstad [email protected] wrote:
|
|
ok thanks for the link.
Ok so this is just completely subjective. for 'setup', ::init() doesn't seem wrong to me of course, since i've often written '.._init' in C, and when crossing over between C and C++ . Of course if you've been looking at rust for a while, you'll be imprinted otherwise. Perhaps the real issue here is the work in renaming ::new. But you've gone through what I would consider more invasive refactorings already with ~[T] -> Vec and removing @ (@engstad heh . i was going to make a similar comment elsewhere. "just don't reserve barrel, stackable..") |
That's nice... since I'm expecting we be left for most of Rust code with pointers that come through generics and full support for implicit pointer behavior by implementing a trait. |
|
It's not just laziness. On Thursday, May 1, 2014, Francisco Lopes [email protected] wrote:
|
completely subjective. |
|
That's right, it's completely subjective, so every decision we make will On Thursday, May 1, 2014, dobkeratops [email protected] wrote:
|
|
@pcwalton I can't find the thread that @thestinger supposedly linked to. Either way, yes - syntax is always contentious, go for the one you like that solves the problem. In this case; a way to specify the allocator. I'm sorry to hear that there's an evaluation order problem with Uniq::new(5). Perhaps there is a work around? As fine as unique pointers are, they do not solve all problems and I don't feel they require its own special support (in the syntax). |
|
The whole point of the |
I've seen Java code that uses variables named |
|
This thread is generating more heat than light. Please take general conversation elsewhere (e.g., /r/rust). If you are interested in I think most of the debate here comes down to subjectivity. I move that we accept and close this PR, with the understanding that if things turn out to be ugly as hell, there is a possibility of resurrecting |
|
I am going to merge this. This extension to the language is necessary for allocator support, as well as unifying The largest point of debate is losing the |
Turns out we're relying on a bugfix in 1.10.0 which renders 1.9.0, the first release with `catch_unwind`, not usable. Closes rust-lang#59
Move completed RFCs and fixup numbering
No description provided.