[idea] foo !: Bar - type conversion operator

[Centril]

This symbol, and variants of it, have some precedent as a subtyping operator in other programming languages.

Note: This operator is usually written in reverse, T <: S meaning “T is a subtype of S”, for example: 'b <: 'a ⊢ &'b u8 <: &'a u8.

[skysch]

It would probably have to be :>, not >:, otherwise you run into ambiguity with < and >:

let x: bool = a < b >: bool;

[Soni]

There’s no ambiguity there.

[skysch]

Is it

let x: bool = (a < b) >: bool;

or

let x: bool = (a < b >): bool;

[Soni]

The latter. > happens first, just like a < b.into().

Remember that ‘> not followed by an identifier/value/expression’ means ‘into’, and the type ascription operator is none of those.

[skysch]

On second thought, the latter doesn’t make much sense unless ::<> is removed… so maybe there is no ambiguity after all. (Aside from precedence, of course.) Though we’d still be enabling wacky things like a < (b::c < d >: e)

EDIT: Using > as an infix operator, bracketting symbol, and postfix operator is pretty crazy. Here’s another potential ambiguity: a >> b. Is it a.into() > b or a.shr(b)?

[Soni]

>> is longer than > so it parses first (it should be greedy). a > > b is a.into() > b

(and this is where I say ! would be better)

[skysch]

Just because you have a way to resolve an ambiguity doesn’t mean the ambiguity doesn’t exist. It means you have to do real work to understand the code. I’m pointing out these ambiguities not because we need to come up with a way to resolve them, but because we need to understand what will happen when a user types that code. They’re going to expect one thing to happen, and instead get something entirely different – perhaps it silently works and gives confusing results, or perhaps it gives a cryptic error that has nothing to do with what they thought they were doing. (The former being far worse.)

It is not hard to resolve ambiguities – It’s hard to do it in a way that doesn’t frustrate people.

[Soni]

try this Lua code: print(1..0) and then print(1 .. 0)

[skysch]

Do you have a point, or are you just assigning arbitrary homework?

[Soni]

it’s a small ambiguity in Lua. the former errors because 1. is a float.

we (rust) have a similar ambiguity with 1.max(0), 1..max(0) (this doesn’t do what you think it does), 1. .max(0), etc.

[kornel]

Swift has as! and as? operators.

For Rust it would make sense to map as? to TryFrom. However, it looks questionable with the try operator:

let bar = (foo as? Bar)?;

[Soni]

this is why I don’t believe in TryFrom as a trait/operator/operation.

it should be impl From<TryFrom<T>> for Option<U>, IMO. Optionally through a convenience trait so you don’t have to write it like this.

[CAD97]

Interesting, probably stupid idea spitball:

name as? Type desugars to TryFrom::try_from(name)?: Type (where : is type ascription here, and ? is still error bubbling)

[Centril]

Interesting, probably stupid idea spitball:

No, not stupid. That’s interesting! and is worth investigation.

[Uther]

Not stupid at all. Actually, I believed it was how everyone expected the as? operator to work.

[newpavlov]

Others come up with as? idea as well (including me ). The main problem IIUC is how to deprecate some of the current as behaviour (e.g. f32 -> u32 casts, pointer casts, etc.), so it indeed will become a sugar around From.

[Centril]

The main problem IIUC is how to deprecate some of the current as behaviour (e.g. f32 -> u32 casts, pointer casts, etc.), so it indeed will become a sugar around From .

I believe the answer will need to be “Edition 2021” if we want to do that. The as operator isn’t very loved anyways and probably doesn’t deserve to be an operator (i.e. should be relegated to a trait…).

[newpavlov]

I mean we will need set of language intrinsics to handle conversions which are currently offloaded to as. (IIRC it’s currently impossible to convert f32 to u32 other than via as) BTW I am not sure if we indeed need full set of traits to describe all possible classes of conversions in the std. I think they can be first added to num-traits (or similar crate) to mature and implementations will use aforementioned intrinsics.

[Soni]

We don’t need more traits. From is all we need. If you think we need more, you’re doing it wrong.

Wrapping (256u16).into(): u8 == 0u8

256u16.into(): Option<u8> == None

These are simple IMO.