RUST Discussion
-
So why the hell doesn't
()
implementfmt
? Glitch? Oversight? Minor implementation bug?It's not show-stopping, but still... have it print
"()"
, why not?
-
() type
Remember when types had names people could read, pronounce, and infer something from? Like Number, or Integer? Rust seems to be on par with Perl for readability...
-
I'm pronouncing it
void
, which it what it should've been called.
-
$_ ~= /void/ #false
-
-
-
So why the hell doesn't () implement fmt? Glitch? Oversight? Minor implementation bug?
Probably to discourage people from ever using ().Remember when types had names people could read, pronounce, and infer something from? Like Number, or Integer? Rust seems to be on par with Perl for readability...
How do you pronounce (i32, i32) type? I call it tuple of two i32's. Similarly, I call () an empty tuple. Because that's what it is - an empty tuple. Really. That's what it actually is, by language specification. A tuple that has no elements.
-
ThatsTheJoke.rpm
though I'd probably pronounce that "topic does not contain 'void'" >.>
-
So why does assignment return a tuple?
-
No idea. That's stupid.
-
Alright, well now I've completed the Towers of Hanoi (with a particularly fine implementation if I do say so myself), I'm going to need a new programming challenge. I kind of want to play with the traits a bit more—writing the
Iterator
was fun.Anyone have any ideas for my next Rust program?
-
Wait... But you can print out the value of (int32, int32)? If so, why is the empty tuple such a special snowflake? It's still a tuple! The fact that it's empty should have no bearing on it implementing fmt or not. Is an empty tuple just a fancy way to write a NULL pointer?
I am confuse!
-
Ooh, that's a glaring error in the type system, isn't it?!
It's just so Rustosistent!
-
Is an empty tuple just a fancy way to write a NULL pointer?
Actually, I think a null pointer is acheived by assigning
None
to a variable of typeOption<T>
.
-
Wait... But you can print out the value of (int32, int32)? If so, why is the empty tuple such a special snowflake?
Empty tuple means void. It doesn't implement any trait to make it unusable outside of value-returning context, which is where you should only ever use void in any sane language. I think I'll write an RFC proposing either making assignments into statements and not expressions, or disallowing declaration of variables with () type.
-
Does Rust have a way to clear the console? (I tried
println!("\x0c")
but that didn't work).Thinking I might have a go at a Game of Life next, but I need to be able the clear the console if I want it to be animated...
-
-
Does Rust have a way to clear the console?
About as much as C.You might try to learn some graphical library instead of working within terminal, though.
-
Try echoing
"\x1b[2J\x1b[H"
Hmm... no dice...
fn main() { println!("a"); println!("\x1b[2J\x1b[H"); println!("b"); }
C:\Users\devel\scratch\rust>test a ←[2J←[H b
-
About as much as C.
You might try to learn some graphical library instead of working within terminal, though.
Yeah, but let's solve one problem at a time. Todays' problem is @tar doesn't understand @Rust.
If I write a decent enough life simulator, I can always come back later and replace the console renderer with a graphical renderer.
-
Hmm... no dice...
Ah sorry, that’s UNIX-only. Your best bet is probably to run
cls
, or port this code to Rust.
-
Yeah, but let's solve one problem at a time. Todays' problem is @tar doesn't understand @Rust.
Fair enough.As for things you can do now, why not just pad the output with enough newlines?
My next Rust project: a proper library for handling console window (as opposed to input/output streams).
-
As for things you can do now, why not just pad the output with enough newlines?
Yeah, that'll have to do for now...
My next Rust project: a proper library for handling console window (as opposed to input/output streams).
Port
curses
?
-
Port curses?
Never liked that lib. But something very similar Might use curses backend on Linux, unless I invent a better way.
-
disallowing declaration of variables with () type
Oh, great.
While we're at it, let's ban numerical types from having a value of zero, because someone might try to divide by them and cause an error.
While we're at it, remove empty strings. I mean, we can't have values being 0 so
strlen
of an empty string would return an invalid value.Look, from what I read here I don't think Rust is for me so I don't really care that much. But the solution to problems like this is not removing edge cases completely, but having a sane way to handle them. You just end up shifting the issue until you end up with even more confusion.
If what @tar did is illegal, why did the compiler let him do that and choked only when he tried to print it? Apparently Rust creators consider empty tuples as valid a datatype. And I agree. To me, removing the ability to use empty tuples from the language makes as much sense as removing empty strings.
Do I have to reference Oracle's empty string == NULL bullshit here? You can argue about the usefulness of the distinction, but it's undeniable the two are not the same. An empty tuple should be as valid as any other.
Filed under: Leave empty tuples alone!
-
I was thinking about this a little more, and I think making the return value of assignment be
()
is actually a , because it means that you can write code likelet a = (b = c);
, and that legitimately compiles, but leaves you with a value ina
that you can't really do anything useful with, and will probably give you an error later on (e.g. when you try to print it (see upthread)).If assignment isn't going to give you a useful value , then it's better for it just to cause a compile error at the point where the error was made. Either
a
has the value ofc
, or thelet
statement fails to compile. What we currently have is the worst of both worlds.
-
-
No, no, no, I was talking about the kind of language used by people who work on the docks...
-
Very similar to the language used by people who have to use MS's console API.
-
While we're at it, let's ban numerical types from having a value of zero, because someone might try to divide by them and cause an error.
Except zeros are useful sometimes. () is never.Look, from what I read here I don't think Rust is for me so I don't really care that much. But the solution to problems like this is not removing edge cases completely, but having a sane way to handle them.
There is no sane way to handle void variables.You just end up shifting the issue until you end up with even more confusion.
@tar's confusion came from the exactly opposite thing - that () is treated just like any other tuple.If what @tar did is illegal, why did the compiler let him do that and choked only when he tried to print it?
Because it is legal. But in my opinion it shouldn't be.Apparently Rust creators consider empty tuples as valid a datatype. And I agree. To me, removing the ability to use empty tuples from the language makes as much sense as removing empty strings.
Except empty string is of string type, along with all other strings, so it's actually useful. Empty tuple is of type empty tuple, with the only valid value of type empty tuple being empty tuple. Not useful at all. Kinda like a single-variant enum, except enum can be useful in some crazy hackish code because you still can declare some methods and traits on it, and you can do scoping - with empty tuple, you can neither.
-
Because it is legal. But in my opinion it shouldn't be.
I suspect we may all be in agreement. But where's the fun in that?
-
Okay, I just talked with one guy on IRC, and apparently there is an actual use case for () type - implementing a Set datatype in terms of Map<Key, ()>.
-
Oh well, now I want to find a use case in my own code
>:D
... Hmmm...Option<()>
, anyone?
-
-
More docs! I just found this tutorial!
-
Oh well, now I want to find a use case in my own code >:D... Hmmm... Option<()>, anyone?
Did you mean bool?http://lukaszwrobel.pl/blog/ruby-is-nil
From what I see, it's more like null than void.
-
As in, this use case is null-and-void? ;)
-
More docs! I just found this tutorial!
Seems very outdated - the Pointer Types section, for example, talks about ~-pointers, which are not a thing since at least last summer.
-
Okay, I just talked with one guy on IRC, and apparently there is an actual use case for () type - implementing a Set datatype in terms of Map<Key, ()>
Yeah, but that runs into the exact same problem of not being able to
println!("{}")
a variable of that type?
-
Yeah, but that runs into the exact same problem of not being able to println!("{}") a variable of that type?
Yes, but mostly because Map doesn't implement fmt::Display either. Actually, almost no standard library types implement this - unlike fmt::Debug trait, which is used for debug printing, and uses {:?} instead of {} in format string. () implements it too - and unsurprisingly, it prints ().fmt::Display is the new name for fmt::String. For some reason beyond my comprehension, the compilation error still refers to fmt::String however.
Seems like I was wrong on the whole empty tuple thing - it's actually a first-class type acknowledged by Rust devs and it's not discriminated in any way.
-
And I was confusing {} and {:?}
-
@tar said:
Oh well, now I want to find a use case in my own code >:D... Hmmm... Option<()>, anyone?
Did you mean bool?Well, what do you know...
type Test = Option<()>; fn main() { let troo:Test = Some(()); let falze:Test = None; println!("{:?} {:?}", troo, falze); }
-
Why would assignment return
struct{}
? Why would it return anything at all? Why isstruct{}
a special case? It's not in Go.
-
Why would assignment return struct{}?
Not struct{} - it's ().Why would it return anything at all?
Because everything is an expression, I think.Why is struct{} a special case?
Because it's illegal construct.It's not in Go.
The official WTDWTF Go Developers Secret Club Thread is that way
-
Not struct{} - it's ().
They're exactly the same thing - a zero-byte-width data structure that has no use other than being a value in a map to make it work like a set.
-
They're exactly the same thing - a zero-byte-width data structure that has no use other than being a value in a map to make it work like a set.
Except Rust doesn't have anonymous structures. Also, () has bit more uses than struct{} - namely, void type and no-op.
-
Because a tuple with no elements means no-op and void.
-
Maybe I'm confusing it with some other new-fangled language, but wasn't Rust explicitly designed to not have/require "Null" (or equivalent)?
I remember an essay from some language designer about what a mistake the existence of "Null" was, and I seem to recall Rust being one of those languages to eschew it. But I'm too lazy to look it up on Google.
-
Remember nullity, the replacement for "division by zero doesn't have a meaningful answer" that also required special cases for everything and was just a renaming of NaN?
Yeah, Rust basically invented NaNity.
-
So I did some googling:
https://news.ycombinator.com/item?id=1952873Look deeper, there is a rich world of Programming Language history and research linked from Rust's FAQ. Don't cling to your Java or C/C++ null pointers.
Which points to:
I call it my billion-dollar mistake. It was the invention of the null reference in 1965.
Which is fucking hilarious because:
pub fn null<T>() -> *const T
[-]
Creates a null raw pointer.