Pre-RFC: impl From<bool> for i32 and impl From<i32> for bool

[nodakai]

How do you like

let b: bool = 123_i32.into();
let i: i32 = true.into();

compared to

let b = 123_i32 != 0;  // no "as bool" in the language
let i = true as i32;

My position is to take every possible action to reduce the uses of the as keyword which looks to my eyes too error-prone. So impl From<i32> for bool is just a bonus

Obviously this can be extended to impl From<bool> for i8 etc etc.

Slightly related: impl From<i16> for isize etc:

Add additional automatic conversions to usize/isize.

Update: perhaps more importantly, this is the PR to be extended by my proposal:

Implement conversion traits for primitive integer types

[bluss]

Don’t add From impls if you don’t think they make for good argument conversions.

As in (playpen)

fn absolute_32_bit<T>(a: T) -> i32 
    where T: Into<i32>
{
    a.into().abs()
}

Every From turns into something that can be used with Into, and that is an argument conversion trait. I admit, I don’t see much realistic use for Into<i32> either. But should this function for example accept booleans automatically? I can see it sort of make sense for i8 and i16, but not bool.

[briansmith]

My position is to take every possible action to reduce the uses of the as keyword which looks to my eyes too error-prone.

I agree that we should be working towards deprecating and removing the as casting feature as it is error-prone. However, I don’t think implementing these From instances should be part of that. I would say that let b = 123_i32 != 0 and let i = if b { 1 } else { 0 } are the best ways of doing the conversions you mention. Perhaps these should be put in the style guide.

<bool> as <integer type> and <integer type> as bool should just be deprecated straight away.

[nodakai]

Guys, why do you discriminate against our little i1 (one-bit integral) type? So its “absolute value” might as well also be defined…

… and let i = if b { 1 } else { 0 } are the best ways

Well, this might be arguable…

<bool> as <integer type> and <integer type> as bool should just be deprecated straight away.

Thankfully, the latter is already a hard error:

https://doc.rust-lang.org/error-index.html#E0054

[DanielKeep]

Guys, why do you discriminate against our little i1 (one-bit integral) type?

Because it isn’t a one-bit integral type. It’s a boolean logic value. It’s a completely different domain.

I mean, you could argue that every type in Rust is just [i1; N] for some N, so obviously we should be able to slice a String and get an f32. But that would defeat the point of having a strong type system in the first place.

1 is no more “true” than 4, or 17, or 9275 or -8, or "banana" or vec!["coconuts", "coconuts"] or even 0. Don’t forget that 0 is “true” in the UNIX shell.

“But what about the existence of Into<Vec<u8>> for String?”

… shut up, me.

[briansmith]

“But what about the existence of Into<Vec<u8>> for String?”

… shut up, me.

I agree, that is actually probably worse than any boolean conversions.

[DanielKeep]

I think it’s a symptom of trying to cram every kind of non-primitive conversion into a single trait. One of the reasons I started conv is that you can’t really rely on what an Into or From conversion means. They basically appear to mean “there is a conversion of some sort that will maybe succeed, that might or might not change representation and/or semantic meaning.”

In other words, they’re near completely useless in any generic context.

That said, I don’t want the situation to get worse.

[briansmith]

Daniel, you might enjoy this: http://degoes.net/articles/principled-typeclasses/

[leonardo]

Daniel, you might enjoy this: http://degoes.net/articles/principled-typeclasses/

This is interesting, but also confuses me a little. Are such ideas useful for future Rust developments?

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.