Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Merged
merged 1 commit into from May 2, 2014
Merged

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
47 changes: 47 additions & 0 deletions active/0000-remove-tilde.md
View file
Open in desktop
@@ -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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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