Idea: Change type ascription syntax from `:` to `type` keyword

kornel · 2018-01-29T23:20:16.158Z

Less ambiguity with the struct literal syntax

I think in the type vs struct literal collision, struct is at fault. Everywhere else in the language it’s binding: type, but in struct literals it’s binding: value.

So if any such huge late change is going to be made, I suggest fixing struct literal syntax instead. It could be same as C:

StructName {
   .field_name = value,
   .other_field = value,
}

This will remove the problematic type/value confusion from the syntax. It also makes it more greppable for .field_name = value which finds both obj.field_name = value.

petrochenkov · 2018-01-30T00:34:31.714Z

Syntax is not the reason why the feature is in limbo (also there’s no conflict with struct literals in the current grammar).
The reason is that the feature is under-implemented (coercions) and is not generally useful enough.

Implementing coercions (while keeping soundness) will certainly move the feature closer to the final decision.
Implementing type ascriptions in patterns as an experiment on nightly will also move things in the right direction, I think.

Sources:

github.com/rust-lang/rust

Issue: Type ascription (tracking issue for RFC 803)

opened by nikomatsakis on 2015-03-16

Tracking issue for rust-lang/rfcs#803. Important points:
 Implement the expr:Type syntax
 Ensure soundness with respect to ref positions:
 let ref x =...

B-RFC-approved B-RFC-implemented B-unstable C-tracking-issue T-lang

github.com/rust-lang/rfcs

Issue: Type ascription (ascription of patterns)

opened by nrc on 2014-10-06

closed by nikomatsakis on

Post-1.0, we would like to allow arbitrary type ascription - that is annotating any expression with a type. E.g., let _...

T-lang postponed

jnicklas · 2018-01-30T13:42:17.101Z

IMO the motivation section of the type ascription RFC is really weak, and since it still hasn’t been stabilized after all this time, it seems to me like Rust works just fine without it. It’s at best a slight convenience in some cases, whereas it restricts the design space for other features (e.g. named arguments). Can’t we just scrap type ascription altogether?

jnicklas · 2018-01-30T13:43:23.180Z

That being said, I like this version much, much better than the current syntax, and I’d definitely prefer type over the :.

Centril · 2018-01-30T17:37:22.938Z

If we can, I’m strongly in favor of keeping the : symbol here. Notably, this was not a symbol chosen at random and comes from typing judgements in type theory and lambda calculus. https://ncatlab.org/nlab/show/judgment, https://en.wikipedia.org/wiki/Simply_typed_lambda_calculus#Typing_rules This notation is also used by a variety of functional languages.

Also; I’d prefer it if we did not scrap type ascription. To me, it provides a lightweight syntactic mechanism to guide and constrain type inference without turbofish or let bindings and can improve writing flow.

In my view, <expr> type <type> does not read well either while <expr> typed as <type> would, but that is simply too long and verbose.

ExpHP · 2018-01-31T02:43:04.206Z

jnicklas:

Can’t we just scrap type ascription altogether?

Nooo! It’s the only solution we have been promised to the Into/AsRef problem!.. a problem which is only going to become more and more prominent over time:

The `Into`/`AsRef` problem

The author of crate bbbb, being the model Rustacean that he is, writes impl From<aaaa::A> for B rather than having from_a method.
The author of crate cccc, being the model Rustacean that he is, writes impl From<bbbb::B> for C rather than having from_b method.
You call a function that returns an aaaa::A…
…and want to return a cccc::C.
Obviously, func().into().into() will not work.
Have fun.

withoutboats · 2018-01-31T05:41:19.188Z

ExpHP:

Obviously, func().into().into() will not work.

There are several working solutions to this.

let x: B = func().into()
x.into()

<A as Into<B>>::into(func()).into()

The first especially doesn not seem worse than this:

(func().into(): B).into()

jmst · 2018-01-31T19:15:57.640Z

Maybe we could just have a generic always-inline identity function that returns its argument, and use that for type ascription with no language changes:

id::<B>(x.into()).into()

Only difference seems to be that it doesn’t implicitly work for non-movable lvalues, but you need to borrow and dereference explicitly.

zackw · 2018-01-31T19:56:55.424Z

ExpHP:

You call a function that returns an aaaa::A…

…and want to return a cccc::C.

Obviously, func().into().into() will not work.

I am uncertain whether this actually works, but I thought this was the exact thing the turbofish was for?

func().into::<B>().into()

leodasvacas · 2018-01-31T20:26:20.453Z

It’s also possible that type inference will evolve to better handle method calls.

withoutboats · 2018-01-31T20:40:47.461Z

zackw:

I am uncertain whether this actually works, but I thought this was the exact thing the turbofish was for?

Turbo fish like this doesn’t work in this particular instance because the parameter is on trait Into<T> not fn into(self). But there are several other solutions that don’t require this type ascription feature.

FlorentBecker · 2018-01-31T21:15:54.890Z

One may also consider the following syntax for type ascription (indentation is not a problem, as ascription is never needed at the top level anyway):

Toto::from(frobnicate(y).into())
//:        ~~~~~~~~~~~~~
//:        has type u8

It’s a bit awkward to input, but seems like a real gain in terms of legibility.

rpjohnst · 2018-02-01T01:02:15.155Z

I prefer to use from in cases where inference gets confused: C::from(B::from(func()). It doesn’t have the nice method call ordering but it’s rare to have more than one layer of them in my experience, and it matches my preferred String::from as well.

H2CO3 · 2018-02-05T11:37:55.223Z

Isn’t struct literal syntax stable? In that case, it’s not going to change.

(And, to be honest, I don’t like that C-style syntax, it’s harder to type (= is less convenient to access on the keyboard than :) and harder to read too.)

H2CO3 · 2018-02-05T11:40:43.924Z

Can’t we just scrap type ascription altogether?

This! I’ve been programming in Rust so far without once needing to touch type ascriptions. Turbofish and binding annotation are more than enough. Also ascriptions are ug-ly.

derekdreery · 2018-02-05T11:55:25.394Z

Isn’t struct literal syntax stable? In that case, it’s not going to change.

I think it can change over an epoch (that’s the point of epochs), but only if it is a really, really big improvement over the current arrangement.

ExpHP:

Obviously, func().into().into() will not work.

This looks like the diamond problem.

H2CO3 · 2018-02-05T13:10:45.389Z

I think it can change over an epoch

Oh, that’s right.

but only if it is a really, really big improvement over the current arrangement.

Sure — which I don’t think it is.

bjz · 2018-02-06T07:28:36.870Z

This also frustrates me when refactoring - moving let bindings into a struct for example. Have to change all the symbols. And it’s the syntax most functional languages use for fields.

I remember @nrc actually tried to propose changing the struct syntax pre-1.0 - would be cool to see it come up again as something to change across epochs, but I’m not sure it would have enough drive to get through.

burakumin · 2018-02-12T12:46:12.957Z

I definitely concur with @kornel. The source of the problem is the struct syntax, not type ascription. Now I would like more details in the pre-rfc: is the struct field initialization (as I believe) the only possible ambiguity? Or are there other subtle cases?

system · 2019-03-25T08:29:36.015Z

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