|
Jabor posted:I'm not sure why you'd claim C++ somehow has better immutability Where did I claim that? What's different about C++'s const keyword is that it actually means something, because in C++, you have real mutability built right into the language. Rust doesn't have that. Rust's mutable borrows are essentially syntactic sugar, they give you no new capabilities that you'd have lacked without them. In particular, well, first, let's suppose Rust had "out" parameters (like C# has) so that you can conveniently return extra values without having to add new fields to the return type. (They have to be returned into variables that have been declared but haven't been given a value yet.) Then, instead of writing code:
code:
code:
code:
In the function call, x got moved into the parameter list, and became de-initialized. So you could have x also be used as the output parameter code:
code:
code:
code:
So, in this language without mut (which happens to be just as as powerful as one with mut), what do you do when you really really do want to mutate something? You make a type like this: code:
So that's the real mutability situation. Mutable borrows are an illusion, real mutability comes from RefCell and anything can be mutable if it wants to be. P.S. The Rust docs are poo poo. P.P.S. Oh and now I've discovered that Cell<T> exists too, for primitive types that don't have any sub-structure, which means you can directly overwrite them without checking for (or having) exclusive ownership. Edit: Things get a bit sketchy, however, when you want to use unsized types. It seems like you'd have to pay something, such as a runtime assertion or needless heap allocation -- something that's different than just memcopying a bunch of extra times -- or you'll lose certain kinds of genericity. sarehu fucked around with this message at 12:44 on Oct 11, 2015 |
# ? Oct 11, 2015 08:10 |
|
|
# ? May 28, 2024 00:06 |
|
yo i've never read an actual semi-academic book about programming. i'm gonna try to do one hour a day on something somewhat difficult. I'd be interested in either algorithms, type theory stuff, maybe some math stuff, idk. or maybe something about how computer programs actually work because i vaguely know what the heap and the stack are but after that i'm pretty loving confused. any terrible recommendations?
|
# ? Oct 11, 2015 08:51 |
|
also are there any GOOD programming forums that aren't this and cavern of cobol? that are maybe a little more active?
|
# ? Oct 11, 2015 09:24 |
|
MALE SHOEGAZE posted:also are there any GOOD programming forums that aren't this and cavern of cobol? that are maybe a little more active? I've heard that gamesutra is pretty good for that niche, dunno about general programming though
|
# ? Oct 11, 2015 09:25 |
gonadic io posted:I've heard that gamesutra is pretty good for that niche, dunno about general programming though i think whole 'coding forums' thing now mainly sits on reddit, outside of regional communities
|
|
# ? Oct 11, 2015 12:14 |
|
gonadic io posted:ya, no wannabe functional langs like scala, f#, etc stop you from mutating objects inside supposedly pure data structures. When I see people do stuff like this, I start hating ReSharper a little bit more code:
Same with wanting to sprikle static everywhere!
|
# ? Oct 11, 2015 12:37 |
|
zokie posted:When I see people do stuff like this, I start hating ReSharper a little bit more Idgi, what's wrong with that?
|
# ? Oct 11, 2015 14:07 |
|
pointsofdata posted:Idgi, what's wrong with that? It's pretty misleading because while you cannot outright reassign 'foos' to a different list, you can still just .Clear() it and fill it with different elements, which 99% of the time is the same thing. What you almost always want to do is: code:
|
# ? Oct 11, 2015 14:28 |
sarehu posted:That's because x is an integral type. But with your own type Foo, you can write Maybe it's because I am super jet lagged, but I still don't understand what you are saying here. Rust code:
This doesn't compile, because of the modification of foo.value on line 17. But I'm assuming this isn't exactly what you are talking about--could you fix up this example so that it demonstrates what you are talking about?
|
|
# ? Oct 11, 2015 14:39 |
|
quote:What you almost always want to do is what about unmodifiable lists in that case? doesn't it just depend on what you want to do?
|
# ? Oct 11, 2015 14:47 |
|
MALE SHOEGAZE posted:i'm gonna try to do one hour a day on something somewhat difficult. project Euler in a lang you don't know MALE SHOEGAZE posted:or maybe something about how computer programs actually work because i vaguely know what the heap and the stack are but after that i'm pretty loving confused. try Eric lipperts blog
|
# ? Oct 11, 2015 14:53 |
|
I think the original complaint is that R# suggests const because there are no more assignments, so the programmer dutifully adds it to avoid being nagged by the squiggly line without thinking *why*
|
# ? Oct 11, 2015 14:56 |
|
zokie posted:When I see people do stuff like this, I start hating ReSharper a little bit more same but the lack of var
|
# ? Oct 11, 2015 15:05 |
|
NihilCredo posted:It's pretty misleading because while you cannot outright reassign 'foos' to a different list, you can still just .Clear() it and fill it with different elements, which 99% of the time is the same thing. Now someone can just replace the list instance though and your referenced might be inconsistent. Presumably in the first example you used List instead of a Read-only list for a reason - there's nothing wrong with making a reference to that list read-only.
|
# ? Oct 11, 2015 15:17 |
|
im probably missing something here, but how have you shown that &mut doesn't actually mean anything? youve just shown how a hypothetical language that isn't rust could do the same thing with different syntax?
|
# ? Oct 11, 2015 15:18 |
|
VikingofRock posted:This doesn't compile, because of the modification of foo.value on line 17. But I'm assuming this isn't exactly what you are talking about--could you fix up this example so that it demonstrates what you are talking about? code:
|
# ? Oct 11, 2015 15:19 |
|
pepito sanchez posted:what about unmodifiable lists in that case? yes, access control =/= immutability access control = have a private List and a public IReadOnlyList reference to that list immutability = have a private/public/whatever IReadOnlyList that gets populated during object construction and then cannot be messed with again, whether by internal or external methods
|
# ? Oct 11, 2015 15:20 |
|
sarehu posted:
but this is what i was originally trying to say. if you want mutability then you need to be explicit about it. if you're wrapping values in a Cell then you're being explicit about it and you can't accidentally mix that with normal values: code:
code:
|
# ? Oct 11, 2015 15:26 |
sarehu posted:
How is that different from the following C++? C++ code:
|
|
# ? Oct 11, 2015 15:36 |
|
fart simpson posted:im probably missing something here, but how have you shown that &mut doesn't actually mean anything? youve just shown how a hypothetical language that isn't rust could do the same thing with different syntax? Specifically, that hypothetical language is Rust minus mutable borrows. Or, more strongly, Rust without mutable borrows, without mutable locals, but with Clojure-style recur syntax. And RefCell and Cell end up being the same thing with the same purposes -- "true" mutability instead of just some Haskell programmer's dream of how systems programming should be with linear types and implicit runST everywhere.
|
# ? Oct 11, 2015 15:36 |
|
VikingofRock posted:How is that different from the following C++? That's bad C++ and it breaks the rules of const. For example the C++11 standard library can make certain assumptions about const methods, see 17.6.5.9/3. On the other hand, the Rust code is perfectly fine because there's no expectation that having a &Foo means you can't mutate the Foo.
|
# ? Oct 11, 2015 15:43 |
sarehu posted:That's bad C++ and it breaks the rules of const. For example the C++11 standard library can make certain assumptions about const methods, see 17.6.5.9/3. On the other hand, the Rust code is perfectly fine because there's no expectation that having a &Foo means you can't mutate the Foo. Personally I would claim that that is bad Rust as well, and I would expect that in Rust &Foo would be semantically immutable unless being semantically mutable in immutable contexts was the whole point of Foo. Maybe this is a poor assumption on my part, though. Are there any examples in the Rust standard library (besides Cell, RefCell, and cousins) where &Foo is semantically mutable?
|
|
# ? Oct 11, 2015 16:15 |
|
sarehu posted:That's bad C++ and it breaks the rules of const. For example the C++11 standard library can make certain assumptions about const methods, see 17.6.5.9/3. On the other hand, the Rust code is perfectly fine because there's no expectation that having a &Foo means you can't mutate the Foo. are you sure about this? the only examples you've given of a mutable &Foo have been in your hypothetical version of rust with a different syntax for mutable borrows and when stuff is wrapped in a Cell or RefCell, which are explicitly "Shared mutable containers"
|
# ? Oct 11, 2015 16:25 |
|
quote:The more common inherited mutability, where one must have unique access to mutate a value, is one of the key language elements that enables Rust to reason strongly about pointer aliasing, statically preventing crash bugs. Because of that, inherited mutability is preferred, and interior mutability is something of a last resort. "inherited mutability" is referring to mutable borrows, and interior mutability is using Cell or RefCell. so like, you can wrap all your rust code in RefCells and Rc and get mutability everywhere and defer errors to runtime, but why would that be considered "perfectly fine"? you'd be giving up a big portion of the compelling part of rust, and it wouldnt even be easier to code in that style
|
# ? Oct 11, 2015 16:35 |
|
a cool thing about mutable borrows is that you can statically only have one active at a time of a thing also i think rust's immutability such asit is is mostly about ensuring memory safety, not some higher-level idea of "this semantically shouldn't change"
|
# ? Oct 11, 2015 16:39 |
|
fart simpson posted:are you sure about this? the only examples you've given of a mutable &Foo have been in your hypothetical version of rust with a different syntax for mutable borrows and when stuff is wrapped in a Cell or RefCell, which are explicitly "Shared mutable containers" The example I gave was in the real version of Rust... If you want something akin to C++11's const, which is immutable or at least acts immutable, Rust has the Sync trait for that (I think). And, as with C++, you have to declare it unsafely for your bespoke types. Read the link, it lays down expectations about the mutability of arbitrary non-Sync &Foo pretty clearly.
|
# ? Oct 11, 2015 16:55 |
|
yes, but it was wrapped in a Cell, which is explicitly a mutable container?
|
# ? Oct 11, 2015 16:59 |
|
sarehu posted:The example I gave was in the real version of Rust... i think you have this backwards. pretty much everything is Sync by default: quote:Types that are not Sync are those that have "interior mutability" in a non-thread-safe way, such as Cell and RefCell in std::cell. These types allow for mutation of their contents even when in an immutable, aliasable slot, e.g. the contents of &Cell<T> can be .set, and do not ensure data races are impossible, hence they cannot be Sync.
|
# ? Oct 11, 2015 17:09 |
|
fart simpson posted:yes, but it was wrapped in a Cell, which is explicitly a mutable container? Yeah, and Foo was thus mutable. Foo isn't "explicitly" mutable unless you look at its source code. You have to have personal information about the type to know that it's immutable, just like how in C# or Java you know that String is immutable.
|
# ? Oct 11, 2015 17:22 |
|
Sagacity posted:It's an interesting read! It looks more and more like Ken Silverman lucked out by creating the Build engine just at the right time, but not because of any discernible coding skills outside the realm of 2.5d rendering algorithms. I guess that's why John Carmack and Tim Sweeney had a bit more staying power. there's pretty clearly a spectrum (hurr hurr) here john carmack - but in the way that means he worked 24 hours a day and vacuumed up 600-page books and siggraph lectures ken silverman - but in the way that everything he does is idiosyncratic and he refuses outside assistance tim sweeney - he made 2d dos games in his basement and made enough money doing it that he could publish other people's 2d dos games
|
# ? Oct 11, 2015 17:42 |
|
Oh man. I always wondered what the deal was with Silverman prototyping stuff in BASIC.
|
# ? Oct 11, 2015 17:57 |
|
I miss the pos
|
# ? Oct 11, 2015 18:44 |
sarehu posted:Yeah, and Foo was thus mutable. Foo isn't "explicitly" mutable unless you look at its source code. You have to have personal information about the type to know that it's immutable, just like how in C# or Java you know that String is immutable. I guess I don't really see the difference between having interior mutability via Cell in Rust, and having interior mutability via mutable in C++ or even via unsafePerformIO in Haskell. Exposing exterior mutability via any of those is pretty unidiomatic as far as I can tell (though we can debate about the degree of unidiomaticness), but they are all parts of their respective languages. It seems pretty arbitrary to draw a line and say that Rust does not have immutability because of Cell, but that C++ and Haskell do. But at this point I think we are just debating the definition of immutability, which to me is sort of a boring debate, so I'll drop it.
|
|
# ? Oct 11, 2015 18:59 |
|
can someone help me with my terrible programming? I keep getting this error on my lovely little scraper and I have no I have no idea what it means or what the problem is. It runs fine in ipython but when I run it in the terminal I get this error: code:
code:
|
# ? Oct 11, 2015 19:11 |
|
well no language at all has absolute immutability, as you could always hexedit memory or whatever. it's like how java's "finally" isn't absolutely guaranteed to happen, as there's lots of things that is outside of the computer's control - what about it losing power for example? haskell calls itself immutable and referentially transparent, but that doesn't take into account out-of-memory errors, etc ,etc. At the end of the day, these guarantees are ALWAYS made with caveats - in haskell you can assume that there generally isn't usage of the unsafe functions that's actually unsafe, or using the ffi, or anything. having a method that can mutate a supposedly immutable object doesn't seem to be something that's forbidden in c++ or rust, whereas it it's "banned" (but you technically can do it) in haskell. that's the difference as i see it. are there any languages that do their best to not have any escape hatches to the type system/semantics? as I said you can always edit memory so no lang can guarantee it 100%.
|
# ? Oct 11, 2015 19:11 |
|
would it be desirable, as thanks to the incompleteness things you could always have a situation in which the compiler can't prove something but you're sure that it's true. agda, coq, idris, all the proof language have "i'm overruling you compiler" functions or flags or what have you i think.
|
# ? Oct 11, 2015 19:13 |
|
gonadic io posted:would it be desirable, as thanks to the incompleteness things you could always have a situation in which the compiler can't prove something but you're sure that it's true. agda, coq, idris, all the proof language have "i'm overruling you compiler" functions or flags or what have you i think. this is what unsafe blocks in rust are for, when you need to do something you know is memory safe but beyond provability to the compiler
|
# ? Oct 11, 2015 19:18 |
|
vodkat posted:can someone help me with my terrible programming? make sure that url parameter is actually a string
|
# ? Oct 11, 2015 19:34 |
|
uncurable mlady posted:make sure that url parameter is actually a string Thanks! My problem really was that stupid/simple.
|
# ? Oct 11, 2015 19:47 |
|
|
# ? May 28, 2024 00:06 |
|
i really hate python backtraces but i think that's because my primary exposure to them is currently as a response field in a bad api
|
# ? Oct 11, 2015 19:53 |