RUST Discussion

tar

So why the hell doesn't () implement fmt? Glitch? Oversight? Minor implementation bug?

It's not show-stopping, but still... have it print "()", why not?

Yamikuronue

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

tar

I'm pronouncing it void, which it what it should've been called.

Yamikuronue

$_ ~= /void/ #false

tar

@Yamikuronue said:

$_ ~= /void/ #false

use English;

VinDuv

@tar said:

use English;

$ARG ~= /void/ #false

Not sure if that helps...

Gąska

@tar said:

So why the hell doesn't () implement fmt? Glitch? Oversight? Minor implementation bug?

Probably to discourage people from ever using ().

@Yamikuronue said:

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.

Yamikuronue

ThatsTheJoke.rpm

though I'd probably pronounce that "topic does not contain 'void'" >.>

Yamikuronue

So why does assignment return a tuple?

Gąska

No idea. That's stupid.

tar

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?

Onyx

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!

tar

Ooh, that's a glaring error in the type system, isn't it?!

It's just so Rustosistent!

tar

@Onyx said:

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 type Option<T>.

Gąska

@Onyx said:

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.

tar

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

VinDuv

@tar said:

clear the console

Try echoing "\x1b[2J\x1b[H"

Gąska

@tar said:

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.

tar

@VinDuv said:

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

tar

@Gaska said:

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.

VinDuv

@tar said:

Hmm... no dice...

Ah sorry, that’s UNIX-only. Your best bet is probably to run cls, or port this code to Rust.

Gąska

@tar said:

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

tar

@Gaska said:

As for things you can do now, why not just pad the output with enough newlines?

Yeah, that'll have to do for now...

@Gaska said:

My next Rust project: a proper library for handling console window (as opposed to input/output streams).

Port curses?

Gąska

@tar said:

Port curses?

Never liked that lib. But something very similar Might use curses backend on Linux, unless I invent a better way.

Onyx

@Gaska said:

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!

tar

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 like let a = (b = c);, and that legitimately compiles, but leaves you with a value in a 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 of c, or the let statement fails to compile. What we currently have is the worst of both worlds.

boomzilla

@tar said:

Port curses?

Use the console API instead of printing to stdout.

tar

No, no, no, I was talking about the kind of language used by people who work on the docks...

boomzilla

Very similar to the language used by people who have to use MS's console API.

Gąska

@Onyx said:

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.

@Onyx said:

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.

@Onyx said:

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.

@Onyx said:

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.

@Onyx said:

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.

tar

@Gaska said:

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?

Gąska

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

tar

Oh well, now I want to find a use case in my own code >:D... Hmmm... Option<()>, anyone?

Yamikuronue

@Gaska said:

There is no sane way to handle void variables.

Ruby: Is nil? - Lukasz Wrobel

tar

More docs! I just found this tutorial!

Table of Contents

Gąska

@tar said:

Oh well, now I want to find a use case in my own code >:D... Hmmm... Option<()>, anyone?

Did you mean bool?

@Yamikuronue said:

http://lukaszwrobel.pl/blog/ruby-is-nil

From what I see, it's more like null than void.

Yamikuronue

As in, this use case is null-and-void? ;)

Gąska

@tar said:

More docs! I just found this tutorial!

Table of Contents

Seems very outdated - the Pointer Types section, for example, talks about ~-pointers, which are not a thing since at least last summer.

PleegWat

@Gaska said:

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?

Gąska

@PleegWat said:

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.

PleegWat

And I was confusing {} and {:?}

tar

@Gaska said:

@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);
}

ben_lubar

Why would assignment return struct{}? Why would it return anything at all? Why is struct{} a special case? It's not in Go.

Gąska

@ben_lubar said:

Why would assignment return struct{}?

Not struct{} - it's ().

@ben_lubar said:

Why would it return anything at all?

Because everything is an expression, I think.

@ben_lubar said:

Why is struct{} a special case?

Because it's illegal construct.

@ben_lubar said:

It's not in Go.

The official WTDWTF Go Developers Secret Club Thread is that way

ben_lubar

@Gaska said:

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.

Gąska

@ben_lubar said:

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.

Yamikuronue

Because a tuple with no elements means no-op and void.

blakeyrat

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.

ben_lubar

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.

Yamikuronue

So I did some googling:
https://news.ycombinator.com/item?id=1952873

Look 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:
http://lambda-the-ultimate.org/node/3186

I call it my billion-dollar mistake. It was the invention of the null reference in 1965.

Which is fucking hilarious because:

null in std::ptr - Rust

pub fn null<T>() -> *const T
[-]
Creates a null raw pointer.