Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

RFC: Remove `~` in favor of `box` and `Box` #59

Merged
merged 1 commit into from

24 participants

Patrick Walton Alex Crichton Daniel Micay Daniel Fagnan Steven Fackler dobkeratops Ben Striegel julian1 Huon Wilson Nick Cameron Florob James Miller Andrew Steve Klabnik comex zkamsler Adrien Tétar Flavio Percoco Premoli Felix S Klock II engstad Davis Silverman Francisco Lopes Kevin Ballard masklinn
Patrick Walton
Owner

No description provided.

Alex Crichton

This will probably need DST to land completely before entirely removing ~, due to ~Trait (I don't think Box<Trait> works right now).

Alex Crichton

This also may interact poorly with the widely-used ~str (and less-so-widely used ~[T]), at least until DST lands. These are separate types, though, so perhaps they could stay until DST is landed.

Daniel Micay

We could still start replacing it before removing it completely.

Daniel Fagnan

A few questions:

  • Would this keep the same semantics as ~? (I'm assuming it will)
  • Is this going to be the future of the current "something".to_owned()? So it would become box("something")

I think there was a possibility of having Uniq become the library type of ~ which seems to make a little more sense than the more abstract "box" word IMO.

Steven Fackler

@TheHydroImpulse to the best of my knowledge to_owned() would still exist as it would produce a Box<str>, where box("something") would produce a Box<&'static str>.

Nick Cameron nrc commented on the diff
active/0000-remove-tilde.md
((27 lines not shown))
+Add a lang item, `box`. That lang item will be defined in `liballoc` (NB: not `libmetal`/`libmini`, for bare-metal programming) as follows:
+
+ #[lang="box"]
+ pub struct Box<T,A=Heap>(*T);
+
+All parts of the compiler treat instances of `Box<T>` identically to the way it treats `~T` today.
+
+The destructuring form for `Box<T>` will be `box PAT`, as follows:
+
+ let box(x) = box(10);
+ println!("{}", x); // prints 10
+
+# 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.
+
Nick Cameron Collaborator
nrc added a note

+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<...>?

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.

Nick Cameron Collaborator
nrc added a note

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).

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.

Steve Klabnik Owner

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.

Nick Cameron Collaborator
nrc added a note

@steveklabnik yes really, box only means heap allocating in Rust and we're are talking about learning the language. I could just as easily write a Box<T> struct which includes a T value by value rather than via a pointer.

Heap allocation is pretty popular in C++ which does not have GC. I think we are being presumptuous to assume Rust will be different. Not saying it won't be, just that it is too early to tell. Especially to early to tell people what they "should" prefer when there isn't an objective argument for it.

Nick Cameron Collaborator
nrc added a note

@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.

Kevin Ballard
kballard added a note

I agree with @nick29581. I'm ok with removing ~expr, but I would really like to see ~T stay.

masklinn
masklinn added a note

box only 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

@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.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
dobkeratops

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?
C++ with nice sugar, a clean break to redesign syntax and make it look less of a mess than C++ does with everything retrofitted into C syntax with templates..

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

Daniel Micay

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 box expression.

Whats going to happen with move semantics, will there be generalized mechanisms for that

There's already nothing special about unique pointers in regards to move semantics.

Ben Striegel

I think that the success of removing ~ entirely (i.e. not even leaving it as sugar) is contingent on the oft-repeated assertion that unique pointers are rarely necessary. I agree that the language would be cleaner without it (and I'm less and less sad at this fact as time goes on), but I think we'll be hurting unless we're certain that it's not common enough to warrant sugar.

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.

dobkeratops

" 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".
its crazy when people seem to know what someone elses use case is :)

Whats the compiler itself going to use, isn't it all @ at the minute, set to change.
i think ~T gets used as an optimization for enums too, to keep the variants a comon size (store some of the data from the larger variants in ~T extention )

Daniel Micay

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".

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.

dobkeratops

" and those lines are almost always incredibly short.", yeah with nice sugar, they're pleasingly short :)

julian1

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.

Daniel Micay

@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 box keyword a single time to create a node. You'll need to spell out Box<T> a single time in the type definition for each child. If it has a variable number of children, then unique pointers aren't involved at all.

dobkeratops

ok well, i can setup the text editor shortcut and keyboard macro to write a symbol. Option<~T> could be OptUniq<T> or OptBox<T> (whch is it?) - i hope you get this in the stdlib, along with VecUniq<T>. That would ease the pain, we'll all be making those types ourselves otherwise

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 Uniq@T , Rc@T etc were synonymous for Uniq<T>, Rc<T> etc. Then you'd have the potential to substitute that with a single macro keystroke, and single visual character in emacs "pretty-mode".. whatever character would make sense to repurpose for that.. @ reads ok i think since you're used to seeing 'adresses' with an @ in the middle)

Daniel Micay

@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.

julian1

@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?

Daniel Micay

ok well, i can setup the text editor shortcut and keyboard macro to write a symbol. Option<~T> could be OptUniq or OptBox (whch is it?) - i hope you get this in the stdlib, along with VecUniq. That would ease the pain, we'll all be making those types ourselves otherwise

I can't really see why the standard library would include a bunch of type aliases for rarely used patterns.

I had a suggestion which might sound crazy, to use @ like haskells' $ as a tool to fight nesting. imagine if Uniq@T , Rc@T etc were synonymous for Uniq etc. you'd have the potential to substitute that with a single macro keystroke, and single visual character in emacs "pretty-mode".. recovering what makes the sigils good. (whatever character would make sense to repurpose for that.. @ reads ok i think since you're used to seeing 'adresses' with an @ in the middle)

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.

https://en.wikipedia.org/wiki/Tilde#Keyboards

dobkeratops

"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

Huon Wilson
Owner

:+1: from me. Some people have got the misconception that ~ is some magical "ownership operator" or just generally over use it (e.g. the constructor for a struct returning ~Struct).

If box were used as a general pattern operator, we may want overloadable MoveDeref or else things like let box v = box vec![]; wouldn't work. That said, I think by-ref bindings are probably enough for an initial implementation.

Daniel Micay

@julian1: I have a hard time seeing Some(~x) as cleaner than Some(box x). The latter is easy to type on any keyboard without any modifier keys or memorization of key combinations. It's also very easy to search for the meaning of the box expression. I'm sure you wouldn't be happy if Rust used accents or East Asian characters as part of the syntax, and that's exactly how tilde feels to many people without a US keyboard layout.

dobkeratops

been on uk keyboards and mac keyboards, ~ is fine :)

Daniel Micay

@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.

Nick Cameron
Collaborator

Yeah, I think the fact that ~ is not present on non-anglo keyboards is pretty much a killer argument in favour of this RFC. Which given the reasons I don't like it above, is kind of a shame.

Florob

If ~ is truly not available on some keyboard layouts at all that is indeed a strong point. If it is just uncomfortable, then I'd warn against going down that line of argumentation too strongly. At least on a german keyboard (and I think plenty of other layouts) {} and [] are about as hard, if not harder to type than ~, and I doubt we're getting rid of those even though they are far more common.

James Miller

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 ~ was the easiest option.

Andrew

So, since this is a major language change, I'd like to weigh in here too :smile_cat:

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 box. I realize that owned pointers are something that should be discouraged, and that typing a tilde on a non-US English keyboard is difficult, but this is probably the first RFC that has actually made me think "I wish this didn't happen". What people find "nice" is quite often subjective, but in this case, put me down for one more person saying "I subjectively find the ~T syntax to be nice and would prefer that this sugar remain".

Also, some things to consider:

  • If people have an issue with typing ~T, if it's just sugar, they're free to type it out explicitly as box T.
  • As with many low-level languages, different data structures can often have a large effect on performance, and assuming that people writing recursive datastructures is an uncommon case seems like an over-general statement to make. E.g. in game development, using strange data structures like Octrees or VP Trees isn't uncommon.

My 2¢ :smiley:

dobkeratops

yes, tree structures are very common in graphics. scene graphs, hierarchies.
how you can proclaim 'people shouldn't be using these'...
it is as a graphics programmer that the rust I originally saw was so appealing.. compact syntax for the trees of vectors that i'm writing all the time, elegant function signatures for dealing with them.

Daniel Micay

If people have an issue with typing ~T, if it's just sugar, they're free to type it out explicitly as box T.

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.

As with many low-level languages, different data structures can often have a large effect on performance, and assuming that people writing recursive datastructures is an uncommon case seems like an over-general statement to make. E.g. in game development, using strange data structures like Octrees or VP Trees isn't uncommon.

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 Box<T> type will only be spelled out in the type definition, not in the code implementing and using the data structure.

Steve Klabnik
Owner

I think it's a much better idea to remove the sugar, start using this, then reconsider the sugar.

A big +1 here.

Daniel Micay

yes, tree structures are very common in graphics. scene graphs, hierarchies.
how you can proclaim 'people shouldn't be using these'...

This is a straw man, I didn't say this. The Box<T> type doesn't need to be written out in code using or implementing a recursive data structure. It's only written in the type definition itself, and those are few and far between. There's also little need to count every character there since I've never seen a case where a field's type (the child) took too many columns.

Andrew

As with many low-level languages, different data structures can often have a large effect on performance, and assuming that people writing recursive datastructures is an uncommon case seems like an over-general statement to make. E.g. in game development, using strange data structures like Octrees or VP Trees isn't uncommon.

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 Box type will only be spelled out in the type definition, not in the code implementing and using the data structure.

Right, no offense intended - I'm not trying to put words in anyone's mouth here. My point is that, when you're trying to decide whether or not syntax sugar is worth keeping in the language or not, I don't know that it's possible to say - in a general sense - that a certain use-case isn't going to be popular/common/whatever. And being able to write something like the aforementioned Cons(1, ~Cons(2, ~Cons(3, ~Nil))), or some variant thereof for other recursive datastructures, is, in my opinion, much nicer than the variant with box: Cons(1, box(Cons(2, box(Cons(3, box(Nil)))))).

That being said, I totally agree with your argument that it's adding two ways of doing the same thing - I just happen to believe that, in this case, that complexity is warranted.

Daniel Micay

Can we define syntactic sugar? A tilde is harder to type than box (especially on certain keyboard layouts) and is further away from natural language or mathematics so I view it as syntactic salt. The pointer sigils are often viewed as a barrier for newcomers to the language.

And being able to write something like the aforementioned Cons(1, ~Cons(2, ~Cons(3, ~Nil))), or some variant thereof for other recursive datastructures, is, in my opinion, much nicer than the variant with box: Cons(1, box(Cons(2, box(Cons(3, box(Nil)))))).

You would write a cons function here instead of using either box Cons(...) or ~Cons(...) so I'm missing where there's any real world difference. It's just a contrived example with no counterpart in real Rust code where functions are used. Owned data structures with nodes exposed are not useful. A singly-linked list built on owned pointers gains nothing from exposing the raw nodes... it's only useful to have the actual nodes if there's shared ownership.

Owned singly linked list are a useless type and if the language makes people avoid them it's not a bad thing. Data structures using a memory allocation per node are usually quite inefficient and there are better alternatives available (vectors, ring buffers, hash tables, b-trees, tries).

Daniel Micay

one thing that is said is that ~T can't take custom allocators, but in C++ you an associate an allocator with a type - you don't need to pass parameters to operator new to make instances of class Foo go through some pool. Is it possible that rust could get the same ability?

~T isn't going to support an allocator type parameter, and that's the problem. You would need to come up with an unambiguous syntax for doing it and then hard-wire a specific allocator design into the language. That's really not something we should have in the core language.

Elsewhere you're claiming the ~ character is hard to type :) For that audience, they won't want that sugar repurposed for something else.

It's harder to type but it's a bit shorter. It's arguable whether it counts as sugar, especially when most people find written terms easier to read than language-specific uses of symbols.

going through type specific pools, memory allocation can be fast.

Unique pointers won't support this unless they're in a library...

There's lots of helper code involved in generating & processing them, working on and returning intermediates.

Sure, and as I've stated many times already none of this count will have Box<T> written out. It occurs a single time in the type definition for each child.

Well I get that without ~[T] the ~ is less appealing, but to me that says how good ~[T] was. std::vector or similar is used most of the time.~str aswell. You see the ~ and you know that it referred to 'a pointer to something allocated'. Having such a compact sugar for it was great. Passing slices around is going to be common too, i hope &[T] stays.

Those aren't pointers to something allocated, they're a struct with a pointer field. It makes as much sense as special-casing hash tables and using ~T for them because there's a pointer to data inside... why are these types special, but you don't feel the same way about all the others?

Having to type more in the code that optimises data structures makes it harder for me to reduce allocations, not easier.

That's a good argument for switching away from a symbol that's hard to type. As long as you're a good touch typist, I think box is easier than shift + reaching for tilde. It's far easier on keyboard layouts where there's no tilde key at all, and those aren't uncommon.

James Miller

I think it's a much better idea to remove the sugar, start using this, then reconsider the sugar.

would you consider keeping the sugar, then later considering generalising the sugar .
Elsewhere you're claiming the ~ character is hard to type :) For that audience, they won't want that sugar repurposed for something else.

Umm, I said that and haven't made an argument relating to the ease of typing the character.

My reasoning for that stance, by the way, is that the box expression is going to happen anyway, for reasons only tangentially related to ~. As such, I don't think having two ways to do the same thing should exist because of speculation that code without ~ will be so hard write. If it turns out it is, then we can re-evaluate then.

dobkeratops

"It makes as much sense as special-casing hash tables and using ~T for them because there's a pointer to data inside... why are these types special, but you don't feel the same way about all the others?"

hah I have actually suggested [K=>V] as sugar for the hash table type, which would complete the ability to write all the most commonly useful types easily. But thats not such a serious idea. (decltype or return type inference, and things related to struct inheritance are probably my biggest language wishes..)

"~T isn't going to support an allocator type parameter, and that's the problem."

but C++ manages it by associating the allocator with the type. To create the object, you use the same operator new, with no parameters, and it can select a custom pool, for the type.

Daniel Micay

I don't think collections should be hard-wired into a systems language. There are many approaches to implementing these, and one specific way doesn't deserve to be placed above all the others. This discourages using the right tool for the job. A rope or small vector shouldn't be any noisier to use than the Vec<T> implementation of a dynamic array. Rust wants to compete with C++, and that means placing library-defined types at the same level as user-defined types and only implementing sugar usable by every type - not hard-wiring special cases for certain implementations of collections and smart pointers.

but C++ manages it by associating the allocator with the type. the same operator new, with no parameters, can select a custom pool, for the type.

The only way that makes sense in Rust is doing it via an optional type parameter. It's not the same language as C++ and there's no room for something like the allocating version of operator new with overloading.

dobkeratops

but you can have a few common defaults that are used 'most of the time', until you've profiled or used situation specific knowledge to optimise.

In our cases, the 'tools code' was written in C/C++ because we could share headers and libraries with the runtimes - but the constraints for tools code were very different. (different optimisation vs convinience tradeoff). if it took 6 mins instead of 4mins to export a scene, thats not as big a deal as if the game runs at 30fps or 20fps. just by a faster PC for the exporter.

It was convenient to be able to move code back and forth, for example to save time trying a feature out, you might do some of the pre-process on loading, in the runtime. And then optimise your loading times by removing it, refactoring your datatstructues by updating the tools based on what you learned experimenting. you could hardly move to 'python' for doing that, you needed it done "inplace".

The more the same language can deal with extremes of convenience and optimisation... the better.

Andrew

So, I'm not nearly invested in this enough that I want to get into an argument about it, so I'll bow out now, but I wanted to make an observation about the underlying point. In my personal opinion, I don't think it's possible to say with generality that recursive data structures with allocation are something that should always be uncommon while using Rust. There are a couple of cases that I can think of that might be common, although I haven't put that much thought into them. For example:

  • Filter chains, where you create a series of sources / filters / sinks and nest them. This is common in audio processing, and some other libraries like CryptoPP use this too. The reason you'd want heap allocation using ~T and not stack allocation is because the state associated with one may be too large to copy.
  • Recursive data structures that you'd like to build directly. Yes, you could use a cons function, but perhaps you'd like to implement it manually, without the [potential] overhead? I'm sure that there's other use cases that I haven't thought of.

Anyway, what I'm getting at is that I feel it's not possible to say with generality that "directly using box(T) or ~T will be uncommon", considering the possibilities inherent in a systems language. And as a second point, if one is using that syntax, I personally find the ~T variant to be much nicer than the box(T) variant.

Either way, I'm not a core dev and in no way responsible for any language direction, so please take this with a grain of (possibly syntactical) salt :smiley_cat:

julian1

Clear and simply expressible recursive data types, are one of the two primary motivations for me to investigate and choose the Rust language over other alternatives C/C++/Java/C# (The other is stack-closures). I'm interested in tree geospatial data-structures kd, oct etc, ASTs for lightweight and embedded languages, and for message and data (scientific and financial etc) encoding.

There needs to be a very strong case to drop the primary syntactical support for this functionality before changes are made.

The concerns and confusion about inappropriate use of ~ could in the majority of cases be addressed in documentation and tutorials by limiting discussion to the context of boxing ADTs.

Huon Wilson
Owner

Maybe Rust can learn by experimenting with not having the ~ sugar ;) we can always add it back later.

Daniel Micay

I don't think it's possible to say with generality that recursive data structures with allocation are something that should always be uncommon while using Rust.

This syntax does not make recursive data structures any easier to write. Holding shift and reaching for the top left corner of your keyboard is not easier than typing "box", and it's significantly worse on some layouts.

Recursive data structures that you'd like to build directly. Yes, you could use a cons function, but perhaps you'd like to implement it manually, without the [potential] overhead? I'm sure that there's other use cases that I haven't thought of.

Factoring out a pattern into a function has no overhead... Rust is built on the assumption that there's a backend with reliable/predictable iterative inlining and it's a correct assumption for rustc. There's no case for having he nodes of the data structure directly without shared ownership. It's an implementation detail leaking into the public API if you're exposing it.

Anyway, what I'm getting at is that I feel it's not possible to say with generality that "directly using box(T) or ~T will be uncommon", considering the possibilities inherent in a systems language. And as a second point, if one is using that syntax, I personally find the ~T variant to be much nicer than the box(T) variant.

It's uncommon, even when all you're doing is writing recursive data structures. It's also easier to write "box" than getting a tilde even on the US QWERTY layout.

Clear and simply expressible recursive data types, are one of the two primary motivations for me to investigate and choose the Rust language over other alternatives C/C++/Java/C# (The other is stack-closures). I'm interested in tree geospatial data-structures kd, oct etc, ASTs for lightweight and embedded languages, and for message and data (scientific and financial etc) encoding.

Recursive data structures will not be any less clear or easily expressible without this special-cased syntax.

There needs to be a very strong case to drop the primary syntactical support for this functionality before changes are made.

I think there's a strong case for dropping it, and I've yet to see a well reasoned argument for keeping it beyond a sentimental attachment or familiarity. You never actually write out the Box<T> type outside of the type definition when writing a recursive data structure. You only need to write box in the function allocating new nodes, and you are going to have that function in sane code to avoid pointless repetition with or without the tilde syntax.

Good language design is all about reducing complexity and redundancy. Rust has strived to remove non-orthogonal features for a long time, and the language has been getting steadily smaller and simpler. There needs to be a strong argument for keeping confusing special cases in the language, and no one is making even a weak argument for keeping it.

The concerns and confusion about inappropriate use of ~ could in the majority of cases be addressed in documentation and tutorials by limiting discussion to the context of boxing ADTs.

This is already covered well in the tutorial and it continues to be a source of confusion. If you're not someone who spends time helping newcomers on #rust or elsewhere then you're in no place to make a claim about this.

dobkeratops

you've got the experiment, its called C++. we came here because we wanted something different.
if its just C++ with a static analyzer, we're better off sticking with our existing knowledge, existing source, existing mature tools.

The fresh syntax and promise of a wider spectrum of convenience vs optimization is/was a really big draw.

i've already explained how, we dealt simultaneously with low level code that couldn't tolerate any allocations (which is why I like convenient casting..) , and rapid experimentation. you don't want to switch language for that, you need it all in the same source base, in the same program.

Rust so far seems to have shown you can actually design a language which can be efficient and more convenient than C++. (the ability to get a lot done with functions , without having to write a lot of boilerplate class declarations and wrapper functions and so on)

James Miller

For some reference, less than 2% of the lines in the very new libregex contain a ~ in them, the majority of these are for constructing the AST, however it would not be difficult to refactor the code to use less explicit instances of ~, instead having one slightly higher in the expression tree. As a prefix for a type, excluding ~str, there are only a handful of instances, and only in the AST.

The rest of the instances are pattern matching on the variants of a passed Ast type, which can be trivially worked around in this case by de-referencing the pointer in the match expression, it's semantically equivalent here.

Daniel Micay

The pattern matching syntax wouldn't be lost, since that could reuse the box keyword for any type implementing the dereference traits.

comex

Although I know it's off topic for this RFC, I think it would be nice, and would more than make up for increased verbosity here, to change the generic syntax. Specifically, I suggest allowing the brackets to be omitted for single argument generics: Option int and such. Allowing that with multiple arguments would probably make the syntax confusing, but with single arguments it's pretty clear what's going on, and it seems to me that a significant majority of commonplace generics are single argument - Box Option Vec Rc RefCell - so this would save a significant amount of typing in most cases.

edit: This would probably make sense only for generic types.

zkamsler

I am somewhat ambivalent about this. Some thoughts on the some specific points:
1. If the plan is still allow things like let x : Rc<int> = box(RC) 1, then the naming Box may be a bit strange. At least one might not expect to box something into anything other than Box. Naming them the same thing kind of mingles the two together even when they are at least somewhat distinct. Not that I prefer the name Uniq (or new), because I really don't.
2. I thought that I had a second thought, but then I didn't.

Daniel Micay

Rc is a wrapper around unique pointers giving a box shared ownership by adding fields for reference counting. Since it has shared ownership, the inner RcBox (see the source) and the outer Rc are separate entities, while with a unique pointer the handle has value semantics.

zkamsler

@thestinger Was that in reference to my comment about the naming?

I am aware of the implementation of Rc, I just meant that having a type called Box could lead one to assume that box is tied exclusively with that type, even though one can box things into other types that are conceptually or functionally boxes. It is hardly the end of the world, but is at least something that should be mentioned and considered.

I am firm believer in trying to poke holes in things and seeing how much air leaks out.

Patrick Walton
Owner

you've got the experiment, its called C++. we came here because we wanted something different. if its just C++ with a static analyzer, we're better off sticking with our existing knowledge, existing source, existing mature tools.

This is hyperbolic. You cannot write a sound, useful static analyzer to guarantee memory safety in C++. It is impossible. That is why Rust exists, not to improve on the syntax of C++ (though of course we try to do that where possible).

Adrien Tétar

I also happen to like ~ which I would like to see being kept as a shorthand FWIW.

dobkeratops

"This is hyperbolic. You cannot write a sound, useful static analyzer to guarantee memory safety in C++."

I wouldn't be looking at rust if I wasn't confident that Rust code could have a 1:1 correspondance to things I understood in C++.
Even if it was as much effort as writing the whole of rust, it would still possibly a worthwhile excercise given the volume of C++ in use. It would seem like a hack, but if lifetimes couldn't be infered they could be annotated by a naming convention or the use of smartpointers with a lifetime template parameter.
The analyzer would be a liberty to tell you where it can't analyze, and annotate for where your 'unsafe blocks' are.

The main reason I looked for Rust was a essentially a syntax issue: its the lack of extention methods.

But c++ does have extention methods, through overloaded free-functions.

its just they make your code look a mess, alternating between a.foo(b) and foo(a,b).
A triviality, but i've seen people throw sourcebases away over syntax they dont like. and it seems i have enough of an 'addiction' to the a.foo(b) sugar myself.
it might be the IDEs' ability to give you that dropbox of suggestions after your type the first parameter, or the convenience of chaining.
'convineince of chaining ' is whats happening here too - ~T is easier to compose, one extra character avoids you needing to define new symbols.

then there's 'restrict', C++ can give the efficiency i need but again, messy syntax. I'm hoping rusts' gaurantees will remove the need to annotate 'restrict' manually.

Daniel Micay

@adrientetar: It's known that existing Rust users are familiar with the current syntax and have a sentimental attachment to it. It's a good reason to avoid changing the syntax without justification, but in this case it's going to be a redundant feature adding complexity to the language. It's one of the things brought up over and over as a source of confusion on #rust, and yet it's not giving anything back for the pain it causes.

Daniel Micay

@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.

Flavio Percoco Premoli

:thumbsup: from me! Folks already covered pretty much all my thoughts on this already!

Maybe Rust can learn by experimenting with not having the ~ sugar ;) we can always add it back later

Big +1 here! :cake:

Patrick Walton
Owner

Even if it was as much effort as writing the whole of rust, it would still possibly a worthwhile excercise given the volume of C++ in use. It would seem like a hack, but if lifetimes couldn't be infered they could be annotated by a naming convention or the use of smartpointers with a lifetime template parameter.
The analyzer would be a liberty to tell you where it can't analyze, and annotate for where your 'unsafe blocks' are.

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.

dobkeratops

I really don't think it would work. No C++ in existence would pass the borrow check.
now i didn't say it would be easy, but
the amount of working c++ in existence would suggest safe c++ is possible.

You'd have to basically rewrite the code, at which point there's little point to using C++.

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 :)

Felix S Klock II
Collaborator

@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.

engstad

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.

Adrien Tétar

@thestinger You have a point, Daniel.

Davis Silverman

+1 for removing from the language and re-adding it later if it is deemed wanted.

I think a problem is that people think ~ is used more than it actually is in a post-DST world without ~[] or ~str, and also with the fact that international keyboards sometimes to not even have the tilde key is a very strong argument for removing it, at least for now, from the language.

dobkeratops

"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."

now, strangely I actually react less badly to this if rust was to use a "new" keyword rather than "box" for this purpose.
so first as a stubborn, conditioned C++ person, i'm shown "~"... its outside of my knowledge, but the payoff from 'getting used to it' was big - significantly less laborious to use than the C++ equivalents. Win.

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++..)
a fly in the ointment there- destructuting? match ..{ new x => ..} doesn't look like it makes sense admittedly.

Ben Striegel

@dobkeratops , for historical context, please see this extensive mailing list thread:

http://thread.gmane.org/gmane.comp.lang.rust.devel/6926

Originally, the box keyword was new! Theoretically we could revisit it, but you would need to address all the remaining arguments against new raised in that thread. And that would be an RFC of its own, of course.

engstad

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.

Patrick Walton
Owner
dobkeratops

ok thanks for the link.

the strong precedence we already have of using new() as a static function for types. Path::init("foo")
looks extremely wrong to me.

Ok so this is just completely subjective.
I would claim as later mentioned, "new" for the part that allocates is the way to 'astonish the smallest number of people' c++, Java.. - and convenient for people who have to jump languages; Rust will not exist in a vacuum. it was good that you did aim for c++ familiarity so much.(IMO).

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.
Seems this is just historical path. There was no reason to object to ::new() for initialisation when you had sigils doing the actual job of 'new' , but if you start over, it seems more logical to me to use new for allocation and something else for intiialization (which might just be on the stack).

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..")

Francisco Lopes

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'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.

Patrick Walton
Owner
dobkeratops

It's not just laziness. Path::init() just plain looks ugly.

completely subjective.
i think Box<T>, Vec<T> looks just plain ugly compared to ~T, ~[T] .. now that i've been 'spoiled' by the existing version of rust :)

Patrick Walton
Owner
engstad

@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).

Daniel Micay

The whole point of the box keyword is to generalize an optimization to all smart pointers. The expression ~sub_expr allocates a box, then runs the expression, and runs clean-up code if there's a failure. The box keyword is being added to extend this optimization to all smart pointers and possibly other cases like constructing an element in-place at the end of a vector. It's surely going to be added whether or not the existing syntax changes, so with that in mind it makes sense to remove the redundant, inconsistent and confusing syntax we have now.

Ben Striegel

I really hate the fact that words like 'box' and 'crate' are reserved.

I've seen Java code that uses variables named klass, might I suggest boks and krate? :3

Nick Cameron
Collaborator
nrc commented

This thread is generating more heat than light.

Please take general conversation elsewhere (e.g., /r/rust).

If you are interested in box vs new please file a new RFC or take it to reddit.

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 ~ or adding some other sugar. Any such possibility should be discussed in another RFC.

Alex Crichton alexcrichton referenced this pull request in rust-lang/rust
Closed

Remove ~, add Box #13885

Alex Crichton
Owner

I am going to merge this. This extension to the language is necessary for allocator support, as well as unifying ~ with the other pointer types (Rc/Arc/etc).

The largest point of debate is losing the ~ sugar it seems, and this is a point which can be analyzed after-the-fact (we've got time before 1.0).

Alex Crichton alexcrichton merged commit ff5f67a into from
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Apr 30, 2014
  1. Patrick Walton
This page is out of date. Refresh to see the latest.
Showing with 47 additions and 0 deletions.
  1. +47 −0 active/0000-remove-tilde.md
47 active/0000-remove-tilde.md
View
@@ -0,0 +1,47 @@
+- Start Date: 2014-04-30
+- RFC PR #: (leave this empty)
+- Rust Issue #: (leave this empty)
+
+# Summary
+
+The tilde (`~`) operator and type construction do not support allocators and therefore should be removed in favor of the `box` keyword and a language item for the type.
+
+# Motivation
+
+* There will be a unique pointer type in the standard library, `Box<T,A>` where `A` is an allocator. The `~T` type syntax does not allow for custom allocators. Therefore, in order to keep `~T` around while still supporting allocators, we would need to make it an alias for `Box<T,Heap>`. In the spirit of having one way to do things, it seems better to remove `~` entirely as a type notation.
+
+* `~EXPR` and `box EXPR` are duplicate functionality; the former does not support allocators. Again in the spirit of having one and only one way to do things, I would like to remove `~EXPR`.
+
+* Some people think `~` is confusing, as it is less self-documenting than `Box`.
+
+* `~` can encourage people to blindly add sigils attempting to get their code to compile instead of consulting the library documentation.
+
+# Drawbacks
+
+`~T` may be seen as convenient sugar for a common pattern in some situations.
+
+# Detailed design
+
+The `~EXPR` production is removed from the language, and all such uses are converted into `box`.
+
+Add a lang item, `box`. That lang item will be defined in `liballoc` (NB: not `libmetal`/`libmini`, for bare-metal programming) as follows:
+
+ #[lang="box"]
+ pub struct Box<T,A=Heap>(*T);
+
+All parts of the compiler treat instances of `Box<T>` identically to the way it treats `~T` today.
+
+The destructuring form for `Box<T>` will be `box PAT`, as follows:
+
+ let box(x) = box(10);
+ println!("{}", x); // prints 10
+
+# 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.
+
Nick Cameron Collaborator
nrc added a note

+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<...>?

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.

Nick Cameron Collaborator
nrc added a note

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).

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.

Steve Klabnik Owner

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.

Nick Cameron Collaborator
nrc added a note

@steveklabnik yes really, box only means heap allocating in Rust and we're are talking about learning the language. I could just as easily write a Box<T> struct which includes a T value by value rather than via a pointer.

Heap allocation is pretty popular in C++ which does not have GC. I think we are being presumptuous to assume Rust will be different. Not saying it won't be, just that it is too early to tell. Especially to early to tell people what they "should" prefer when there isn't an objective argument for it.

Nick Cameron Collaborator
nrc added a note

@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.

Kevin Ballard
kballard added a note

I agree with @nick29581. I'm ok with removing ~expr, but I would really like to see ~T stay.

masklinn
masklinn added a note

box only 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

@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.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+# Unresolved questions
+
+The allocator design is not yet fully worked out.
+
+It may be possible that unforeseen interactions will appear between the struct nature of `Box<T>` and the built-in nature of `~T` when merged.
Something went wrong with that request. Please try again.