‘~’ is being removed from Rust • Hacker News Board

Re: ‘~’ is being removed from Rust

#111

Post by stream_fusion » Sat, May 03, 2014, 11:14 AM UTC

loup-vaillant wrote: post #110

4bpp wrote: post #87

Earlier quoted context omitted.

Sorry, I don't think I understand; could you explain what you mean by "exposing unshared nodes"? Also, are you saying that for every self-referential constructor of an algebraic datatype, the correct thing to do is to write a boilerplate function that simply wraps the constructor and a call to whatever the boxing operation winds up being...? That seems somewhat odd.

"Node" is the name I used to talk about the cons cells your singly linked list is made up of. Now 2 things. First, the tiled denotes unique pointers. Your example was a singly linked list. Singly linked lists have 2 important characteristics: adding or removing the first element is O(1), and the tails of those lists can be shared. With unique pointers, you can't share. By design. If you want several references to a "…

Does this change pattern matching syntax of recursive data structures, if every node is an explicit box type? Could be cumbersome for matching parse-trees?

Re: ‘~’ is being removed from Rust

#112

Post by loup-vaillant » Sat, May 03, 2014, 12:38 PM UTC

stream_fusion wrote: post #111

loup-vaillant wrote: post #110

Earlier quoted context omitted.

"Node" is the name I used to talk about the cons cells your singly linked list is made up of. Now 2 things. First, the tiled denotes unique pointers. Your example was a singly linked list. Singly linked lists have 2 important characteristics: adding or removing the first element is O(1), and the tails of those lists can be shared. With unique pointers, you can't share. By design. If you want several references to a "…

Does this change pattern matching syntax of recursive data structures, if every node is an explicit box type? Could be cumbersome for matching parse-trees?

I have read that is doesn't change a thing. Maybe it's even more concise.

From what I have read, there is a general mechanism for pattern matching: let the custom data structure implement a "pattern match" method or something, which is then implicitly called with the pattern matching syntax. The explicit box type would be no different.

My guess is, parse-trees would be just as easy to match.

Re: ‘~’ is being removed from Rust

#113

Post by Ygg2 » Sat, May 03, 2014, 2:39 PM UTC

dbaupp wrote: post #100

Pacabel wrote: post #96

Earlier quoted context omitted.

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.

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 > is a pointer to a pointer to the data: essentially pointless!). In other words, one would write Vec >> That might be considered ugly, but it's not ugliness caused by the `~` change.

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

Re: ‘~’ is being removed from Rust

#114

Post by mcguire » Sat, May 03, 2014, 2:43 PM UTC

bjz_ wrote: post #27

mcguire wrote: post #14

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

It shouldn't be a huge change for users of Rust - `~` is used far less than most people think.

Indeed. Most of the usages I've written have been ~[...] or ~str. I think both have drop-in replacements. (And if I had some bloody time, I'd update my code and find out.) This kind of change doesn't affect how you write code the way that the 1:1 thread/M:N model thing does.

Note: I'm not laughing at you, I'm laughing with you.

Re: ‘~’ is being removed from Rust

#115

Post by pcwalton » Sat, May 03, 2014, 2:55 PM UTC

Ygg2 wrote: post #113

dbaupp wrote: post #100

Earlier quoted context omitted.

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 > is a pointer to a pointer to the data: essentially pointless!). In other words, one would write Vec >> That might be considered ugly, but it's not ugliness caused by the `~` change.

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

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

Re: ‘~’ is being removed from Rust

#116

Post by chromatic » Sat, May 03, 2014, 6:05 PM UTC

eevee wrote: post #64

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…

Perl's OO support as bad as you make it sound. You don't have to use the base or parent pragmas to subclass; it's just a lot less tedious if you do, because there's no special syntax for it. (It's kind of amusing to hear "Perl has too much syntax" in this context.)

Re: ‘~’ is being removed from Rust

#117

Post by sanderjd » Sat, May 03, 2014, 10:30 PM UTC

Pacabel wrote: post #88

sanderjd wrote: post #33

Earlier quoted context omitted.

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.

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. Unti…

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.