←back to thread

207 points mfiguiere | 7 comments | | HN request time: 1.12s | source | bottom
Show context
stickfigure ◴[] No.43539275[source]
Great! Now can we make `final` the default for all fields, variables, and parameters?

(yes yes, I know, that would break syntax... but please come up with something to discourage mutability)

replies(5): >>43539333 #>>43539950 #>>43540550 #>>43541493 #>>43543176 #
magicalhippo ◴[] No.43539333[source]
Const-ness in C++ is something I miss in other languages. Being immediate able to see that this function or method couldn't mutate the object made it so much easier to reason about the code.

Yeah I know there's ways around it, but then the author known what they told the other party to expect.

replies(3): >>43539580 #>>43540000 #>>43555589 #
1. josephg ◴[] No.43539580[source]
Yeah I find it a bit startling going from rust (where const is the default) to basically any other language. Sometimes I look at typescript function definitions and I’m like - uuuuhhh does this function mutate that parameter? Does it keep a reference to it? If the object I’m passing is mutated after I call this function, will something break? It’s impossible to tell from a function signature, even with all of typescript’s type safety. That gives me the willies. - and for good reason, it’s tripped me up lots of times.

Even the JS standard library struggles with this. You just have to remember that .sort() modifies the array in place (and returns it), but .slice() does a shallow clone of the array. (Not a deep clone - that would be different again!)

replies(2): >>43539769 #>>43539884 #
2. mont_tag ◴[] No.43539769[source]
> Even the JS standard library struggles with this. You just have to remember that .sort() modifies the array in place

ISTM that there are almost always some kinds of mutable data structures present in non-trivial programs. And outside of the program, you have databases to directories of files that get mutated by users or other parts of a program. I think this is just a fact of life.

replies(1): >>43539870 #
3. magicalhippo ◴[] No.43539870[source]
The point isn't that there's mutability, it's to be able to easily identify where it is and where it is not.

Languages which lack the tools to do this are just harder to reason about, at least for me.

In the JS example, as a non-JS coder, I would expect that a sort function that returns nothing/void would sort in-place, while a sort function that returns an array would return a sorted copy. I would not expect it to sort in-place and return it.

However in C++ I could easily see from the function definition that it might be doing that, because a sort that returns a copy would take a const reference for the input array. So if I came across a sort function which took a non-const reference as input I'd be able to at least suspect it's doing it in-place.

4. recursive ◴[] No.43539884[source]
> Even the JS standard library struggles with this. ...

I don't think this represents struggling. There needs to be some way to sort in place. Sometimes you need to sort a big array and don't want to allocate.

And there should be some way to clone the array without mutating. That's slice. So you how do you sort a clone? .slice().sort()

I think by far the biggest problem with ES .sort() is that number arrays don't sort numerically by default.

replies(1): >>43540074 #
5. steveklabnik ◴[] No.43540074[source]
> There needs to be some way to sort in place. Sometimes you need to sort a big array and don't want to allocate

Your parent isn't saying there shouldn't be mutation, just that the mutation should be obvious.

In Rust, the type signature for the in-place sort is

  pub fn sort(&mut self)
  where
      T: Ord,
That `&mut self` lets you know that it's going to mutate.
replies(1): >>43540349 #
6. josephg ◴[] No.43540349{3}[source]
Exactly. And for function parameters, rust also (usually) makes it obvious when you’re passing by value, by reference or by mutable reference:

    foo(x); // Moves or copies
    foo(&x); // immutable reference
    foo(&mut x); // mutable reference
I don’t need to look up the signature of foo to understand what happens to my variable. It’s obvious at a glance.
replies(1): >>43540533 #
7. recursive ◴[] No.43540533{4}[source]
Fair point. I guess this is the cost of dynamic languages.