
‘~’ is being removed from Rust - steveklabnik
https://github.com/rust-lang/rfcs/pull/59
======
aidenn0
For those reading, you need to read comments by "thestinger" very carefully.

A lot of people respond as if he made the following two claims:

1) Recursive data structures are rare

2) Singly linked lists are useless

When in fact he made these two claims:

1) _definitions_ of recursive data structures are not prevalent in code

2) _unshared_ singly-linked lists are not useful

#1 is true since you define a recursive data structure only once, no matter
how often you use it.

#2 is slightly less obvious. One of the big advantages of a singly linked-list
over other structures is that you can share tails with multiple lists. With
unique ownership that advantage goes away. (There is still the use-case of
loaning out tails, but that is a fairly weak argument).

Another advantage of a singly-linked list is ease of implementation; that is
negated when your standard library provides dynamic arrays and stacks already
baked in.

------
steveklabnik
Here's a quick summary: Rust is adding a new capability, `box`, which is a
superset of the existing pointer functionality.[1] Therefore, this special
case is being removed, and, if it turns out that `~` is missed, sugar can be
re-introduced to bring it back.

That said, I don't think it will be. It's only really useful in function
signatures, since types are inferred everywhere else, and `~` is harder to
search for, as well as not on all keyboards. Plus, in Rust, you should always
use stack allocation unless you absolutely have to, and so making heap
allocation a little more weighty syntax-wise fits with the goals of the
language. `~` -> `box` isn't that much heavier, either.

1: One way it's a superset: previously, only `~` supported 'placement new',
and now, all pointers can with `box`. `box` also allows you to specify which
allocator you'd like to use.

~~~
phaer
> `~` is harder to search for, as well as not on all keyboards.

Which keyboards do not have a '~' key? How do those people type a path
relative to their home directory? Use $HOME/foo/bar all the time?

~~~
masklinn
> Which keyboards do not have a '~' key?

Most euro keyboards need at least AltGr + key, possibly 2 keys (because ~ is a
dead key, so a space is needed to insert the character itself)

> How do those people type a path relative to their home directory? Use
> $HOME/foo/bar all the time?

It's common to `cd; cd foo/bar`

~~~
luchs
These keyboards usually don't have a convenient way to type {}[] either, these
are AltGr + number keys in the German and French layouts for example.

The keyboard situation doesn't seem to be as bad as for the degree sign °,
which doesn't seem to be typeable on an English keyboard at all.

~~~
simlevesque
French layout keyboards do have a convenient way to type {}[], for me with
Canadian French it is under 7890 using alt.

~~~
Solarsail
French Canadian keyboards are fairly different from European French keyboards:

French Canadian:
[http://www3.uakron.edu/modlang/french/images/kbd4.gif](http://www3.uakron.edu/modlang/french/images/kbd4.gif)

European French: [http://www.fentek-
ind.com/images/frenchkeytop.gif](http://www.fentek-
ind.com/images/frenchkeytop.gif)

------
moogly
I'll be honest: Rust is kind of losing me with these changes. I started
following/tracking the language about a year ago, and I thought the syntax
looked really succinct and easily readable back then, but with changes like
this, [T] => Vec<T>, the region/lifetime syntax, together with the propensity
to abbreviate almost everything, code is quickly starting to look kind of
soupy to me.

I get the arguments, and they're logically sound, but in the end it's
beginnning to read like C++03.

On the one hand, the Rust community's generalising a lot of stuff, which
sounds great, but then adding a bunch of macros (I know, this ain't yo daddy's
C macros) to replace first-class citizens ([1, 2, 3] => vec!(1, 2, 3) for
example), and I worry how IDEs will be able to handle macros from an
autocomplete/intellisense standpoint, not just checking/displaying type
information when using them, but also writing new ones.

I guess it's a language primarily by and for text editor users, and I'm beyond
that point these days.

As I said, I started following the language daily a year ago, and a couple of
months ago I was thinking of jumping in around this point in time, but right
now I feel like I want to wait another year to see if the syntax has become
more readily intelligible.

I still think it's a fantastic effort, and kudos for all the hard work.

~~~
sillysaurus3
_I guess it 's a language primarily by and for text editor users, and I'm
beyond that point these days._

What do you mean?

EDIT: Imagine a programming language designed around an IDE. Fun thought. Not
sure whether it's a useful thought, but it's fun to think about.

~~~
eevee
And we shall call it Java.

~~~
Pacabel
That isn't really the case at all. Java (the language) is relatively small and
simple. Java code can be written quite easily without an IDE. In fact, that's
how it was done for many years by most Java developers, before Eclipse,
NetBeans and other IDEs became more commonly used.

The unnecessarily complex design of many Java libraries and frameworks is
generally what pushed developers toward using an IDE, not the language itself.

------
pnathan
Feh. It's an interesting split between what I'll call the concisionists and
the explicitists.

As a concisionist, this change stinks. I appreciate that the "not on my
keyboard" argument is a big deal, but I'd argue that just merits a change of
sigil, not adding verbosity.

Designing a language to be prolix just makes code more laborious to
understand.

~~~
masklinn
> As a concisionist, this change stinks.

There's two side to it: it makes creating unique pointers slightly harder, but
at the same time it makes (unnecessary) overuse of unique pointers slightly
harder/less likely, and that looks to be a concern of the core team.

> Designing a language to be prolix just makes code more laborious to
> understand.

Does it make the code more laborious to understand though? The concept becomes
easier to search for and it's easier to talk about it (both because box/boxing
is a term of art, and because "box" is a single syllable).

~~~
Alphasite_
I would argue that yes, it does. The examples I've seen of the change have
become a mess of letters and i'm not too fond of it.

~~~
steveklabnik
Could you cite some specific examples? I think that'd really help here.

~~~
Ygg2
Well if you had something like

    
    
         ~Vec<~Vec<~Vec[~T]>> (not 100% realistic example)
    

becomes

    
    
         Box< Vec< Box< Vec< Box< Vec[Box<T>]>>>>>
    

which really looks weird. It's like you have tire marks over your code.

~~~
dbaupp
Sorry, but I think that example is so unrealistic as to not really be worth
discussing.

~~~
Pacabel
I wouldn't be so quick to dismiss it. Maybe that exact situation won't often
arise, but in other languages like C++, Java and C# it's not at all uncommon
to have nested collections.

~~~
dbaupp
Yes sure; but it is rare to have indirection for every layer of a nested
collection (i.e. each collection will essentially be a pointer to some data,
with a little bit of metadata (like length & capacity for a Vec), so having
Box<Vec<T>> is a pointer to a pointer to the data: essentially pointless!).

In other words, one would write

    
    
       Vec<Vec<Vec<T>>>
    

That might be considered ugly, but it's not ugliness caused by the `~` change.

~~~
Ygg2
Could the opposite happen? What if you have `~~` pointer or `~&~` pointer?

~~~
pcwalton
I've never seen `~~` except for workarounds caused by the current lack of
dynamically sized types (which is being fixed). `~&` is not very useful, as
you'd be placing a stack-bounded lifetime on the heap (except for 'static, I
suppose, but I've never seen that).

------
eevee
What bugs me isn't the loss of _this_ shorthand, but the decrease in shorthand
overall.

Punctuation and other built-in language features give me a baseline for what I
can understand and what I can always rely on. If I see ~T, even if I don't
know what it means immediately, I still know that it's part of the core
language and will get me a step closer to useful understanding; here is a
thing I can probably use to solve some problems. Moving as much of the
language into a stdlib as possible is a worthy goal that makes for a "cleaner"
and more "elegant" language (whatever those mean), but it vastly reduces this
effect.

The problem is that all of the core syntax and builtins are probably good to
know, but _not everything in the stdlib is useful_. At least half of the
stdlib for any given language tends to be worthless junk. Do you do Python?
Did you know about the formatter module? popen2? asynchat? sunau? Probably
not. But you almost certainly recognize 100% of Python's syntax and at least
90% of its builtins.

Contrast with Perl, which (besides having a ridiculous amount of built-in
syntax) relegates such basics as _OO support_ into the standard library.
Subclassing is done by using a library, and there are even _two distinct
libraries_ for doing it in the stdlib! So to understand Perl code, you have to
understand a good chunk of its stdlib as well, but not _all_ of it because a
lot of it is weird obscure junk, but there's nothing telling you which bit is
important because it's just a thing everyone knows. (And the reliance on
third-party libraries to fill in gaps in the language makes this far worse.)

One of C++'s major offputting properties is that _everything_ is in a bloody
library. (The other is that the features it does have all interact in obtuse
ways.) You can learn what all of C++'s syntax does, and still be unable to
make sense of real-world C++ code. I'd be pretty sad to see that happen to
Rust.

~~~
loup-vaillant
From thestinger:

> _Rust has strived to remove non-orthogonal features for a long time, and the
> language has been getting steadily smaller and simpler._

Hereby avoiding the one mistake that made C++ so horrible: lots and lots of
non-orthogonal features. It's not just a matter of being cleaner or more
elegant. It's a matter of having less to learn.

As for half the standard library being worthless junk… Rust probably won't be
doing that mistake. If they simplify the language, they are likely to simplify
the standard library as well, which means cutting the worthless junk out.
Plus, it will likely be easy to use whatever is most useful: it will be all
over the place in tutorials, manuals, examples, and of course actual code.

> _One of C++ 's major offputting properties is that everything is in a bloody
> library._

On the contrary, it's an assurance that you can implement bloody efficient
data structures _yourself_ , if the STL doesn't do what you want. This is what
makes C++ a _generally_ fast language: it's not optimized for special cases.

> _You can learn what all of C++ 's syntax does,_

Most programmers can't. Experts do, but for the rest of us… C++ is impossible
to parse, and has many, _many_ , MANY pitfalls:
[http://www.yosefk.com/c++fqa/](http://www.yosefk.com/c++fqa/)

Which is precisely what Rust is trying to avoid.

------
pornel
~ for allocation was weird, but I will miss lack of ~ as analogy to * _.

_ Will they change * to `RawPointer<T>` too? ;)

I'm not happy about change of [T] to Vec<T> either.

I hope all these changes will make a full circle and get a first-class syntax
back.

~~~
tomjakubowski
> I'm not happy about change of [T] to Vec<T> either.

[T] wasn't a thing in Rust. ~[T] hasn't gone and won't go away either. See
this email from acrichton: [https://mail.mozilla.org/pipermail/rust-
dev/2014-April/00935...](https://mail.mozilla.org/pipermail/rust-
dev/2014-April/009352.html)

~~~
dbaupp
That email is somewhat outdated. ~[T] is certainly disappearing with that
syntax, becoming Box<[T]>, andthere has been much back and forth about whether
this Box<[T]> type actually offers anything over Vec<T>, or if it's just a
"cute" consequence of the type system.

(The borrowed slices &[T] and &mut [T] are certainly here to stay.)

------
4bpp
Orthogonally to whether this is a good or bad idea, I really wish the PR and
subsequent community management had been handled more carefully for something
that was pretty much bound to be a very controversial change (tellingly,
/r/rust even had a preemptive thread about it before it materialised:
[http://www.reddit.com/r/rust/comments/236plz/thoughts_on_rem...](http://www.reddit.com/r/rust/comments/236plz/thoughts_on_removing_syntax/)
). Although I perhaps am in a bad position to complain after having been
caught up in the less savoury parts of the exchange myself, I can't help it
but believe that the often outright hostile tone and the swift wagon-circling
by the proponents (in response to what they probably felt was an unreasonable
onslaught of repetitive criticism) will have left a very bad aftertaste with a
lot of readers. Much of this could have been prevented by preparing a clean
document explaining the motivation and ramifications of the change to a
general audience in advance, and perhaps by having the moderators apply some
gentle pressure on the loose guns on either side to pipe it down.

~~~
brson
The OP is, in fact, that document. You'll notice this in a pull request to
Rust's RFC repo. This change has been prominently brewing in the Rust
community for a long time. The fact is that people have strong opinions about
Rust and this is a critical time in its development - people are going to
complain.

~~~
brson
I could have put some more thought into this response.

As Rust becomes more popular while we try to bring home the last few major
changes, we've had this problem a few times, where the broader community is
surprised and partially shocked and disappointed at a change that has been
brewing for a while.

Certainly, more effort could be put into messaging and explaining how big
changes are going to effect users. Figuring out how much, and what sort of,
messaging is sufficient is not easy, and somebody is always going to find
something objectionable about nearly everything. Additionally, Rust is still
in an alpha state, in heavy development. The project is not in production mode
yet.

We're always learning from mistakes and evolving the process.

Finally, Rust is in the home stretch. In some sense, we're at a stage where we
need to hurry up and just get it done, at the expense of some community
fallout along the way. If Rust is good, the ill will from the churn will be
forgotten in time; if Rust is bad it will die. With the attention Rust is
attracting, community momentum wants Rust to stop changing, but Rust _must_
change a bit more. Rust needs to get to a point where the design can be
justified and maintained for years to come, before its own popularity forces
it to slow down.

~~~
4bpp
Thanks for the detailed response. I understand that having to deal with this
sort of situation instead of working on bringing the project closer to
fruition must be very annoying from a core developer's perspective. Sorry for
contributing my part to this being dragged out further.

To clarify, what has distraught me the most about this change is not even the
change itself (although I do think that, however small or warranted on its own
it may be, it may have long-term ramifications that need to be considered much
more carefully), but the way the process seemed to diverge from the fairly
open and inclusive discussion that seemed to regularly take place in the past.
This change may well have been brewing somewhere for a while, but from the
point of view of someone who is not in the "inner circle", what was
perceivable of it essentially was the thread I linked above some 16 days ago
(which was remarkably full of responses by apparent "insiders" that aimed to
discourage people from discussing the topic at that point in time) and the
thread announcing the RFC, in which even some of the most basic questions
needed for a casual observer to understand the tradeoffs were unanswered when
the proposal of the RFC was mainlined something like half a day later.

The end result is something that looks similar to what happened with GNOME 3
to someone who was in the opposing camp in both cases, where the "in-group" at
some point decided that they had identified a development agenda of utmost
importance to what has in fact been part of the central mission of the project
all along, and increasingly came to send the message that they held
disagreeing members of the "out-group" to be obsessive hecklers and people who
should just get out already if they don't like it - although nothing says it
has to end up like that, where this took the state of Linux desktop
environments is easily observed nowadays.

When considering the overall lifecycle of a project, the number of remaining
"difficult decisions" is a far more accurate metric of completion than code or
concept. Frustratingly, it is pretty much bound to increase towards the full
end of the scale of the latter when the development process is a highly public
affair. People wouldn't argue this topic with such ferocity if it wasn't for
their appreciation of your work so far and high expectations for this project;
please don't let that go to waste by shortcutting the decision process when
you have come this far.

------
pbsd
Now that '~' is being removed for pointers, can it be used instead for unary
bitwise NOT instead of '!'?

------
mattgodbolt
Not specifically related to this exact rust topic, but the interest in rust
made me add support to my compiler explorer so you can tap rust code and see
how it compiles interactively at
[http://rust.godbolt.org](http://rust.godbolt.org)

~~~
dbaupp
That's very cool; how do you get colourise to associate lines to the regions
of assembly?

~~~
mattgodbolt
I parse the debug line directives in the assembler output. Something about the
way rust/llvm outputs with -O makes this a little worse than the equivalent in
C++/clang but it's 'good enough' to get the gist of what's happening I think.

~~~
dbaupp
Oh, nice. Rust's debuginfo does seem to have a few peculiarities where lines
numbers don't quite work out (or something, I haven't really been able to
"quantify" it); but there's currently someone working on debuginfo.

------
ben0x539
Gee, with this few sigils remaining, Rust is going to have a very hard time
finding widespread adoption, since it won't stand out from competing
languages!

~~~
pcwalton
We still have "fn". :)

~~~
xiaq
fn is my favorite keyword for function definition. "function" is too long.
"def" doesn't say anything about functions (unless you read it as DEfine
Function). "func" sounds too funny. "defun" always reads "defunct" to me.

And just out of curiosity, where did the rust designers get the inspiration
for "fn"? I know plan 9 rc and clojure have "fn". Or maybe it's independent
invention?

~~~
pcwalton
Well, I slightly prefer "fun", but the Rust community pretty firmly favors
"fn", and they're about the same anyway.

As far as I know it came from ML.

~~~
xiaq
"fun" is even funnier than "func"!

ML etymology sounds pretty plausible (I didn't know ML uses fn) since I can
see there is a strong influence of ML on Rust.

------
cmollis
I like this change.. 'box' is obviously more letters, but cognitively (for
some reason) seems to enforce the operation better.

------
kalail
Honestly. it feels like the language is losing something. I'm having a hard
time identifying what that is, but I think it's something like the 'Rusty-
ness' of the language, similar to how code can be more or less 'Pythonic'.

The language is still in flux and there is only one way to find out whether we
will miss '~'. Let's do it.

------
mcguire
Is this a good time to point out that the language is stabilizing?

~~~
sanderjd
It seems to me that the current focus on "do all the breaking changes we want
to do so that we can get to 1.0" naturally leads to a prevalence of breaking
changes. So in a strange way, yes, this sort of breaking change is evidence of
the language stabilizing.

~~~
Pacabel
I don't think we can really consider it to be "stabilizing" when there are
relatively significant and breaking changes like this still going on.

It may be headed in the direction of stability, but that's quite different
from stabilizing.

We can consider it to be stabilizing once the language and standard libraries
have been frozen, and the only changes happening are very minor ones that are
fixing critical bugs.

Until then, it's still in the research and development stage, at best.

~~~
sanderjd
I think "heading in the direction of stability" and "stabilizing" are the same
thing. But pedantry aside, it does really seem to me that the breaking changes
going on now are fundamentally different in character than those that used to
happen - they are much less about experimental functionality, and much more
about "let's fix as many of our frustrations as possible before we're stuck
with them". For instance, the specific change under discussion would (I think)
be fairly easy to re-add backwards compatibly, but probably impossible to
remove.

But meh, this maybe ours is a (boring) purely definitional disagreement - I
think we can consider it _stabilized_ once the language and standard libraries
have been frozen and only bug fixes and minor changes are occurring.

------
ludamad
When will people get over syntax? It's a bit ridiculous how much time we spend
fussing over ASCII considerations instead of working on novel ways to present
code (making the manner it was written irrelevant).

------
Dewie
Is the comparison to Python that great? A language like Rust has more things
that you have to keep track of yourself, as a programmer. Having English-like
syntax might work great in a language with relatively simple semantics, but I
don't think that it necessarily follows at all that that kind of design scales
to languages where you have to be explicit on the level of pointer types and
such.

------
batmansbelt
That was one of my most used features. This stinks!

~~~
steveklabnik
The feature isn't going away, just the syntax.

~~~
batmansbelt
Oh thank Christ.

