Stream: t-lang

Topic: `{integer}` type arrays


Lokathor (May 08 2020 at 20:09, on Zulip):

This is an idea from the same project that made me post about the literals thing but it's fundamentally different and I suspect far less controversial to change it.

Supposing we have

If you then have code that says Foo::from([1,2]), you get an inference failure because the array is immediately given the type [i32; 2] instead of the more general [{integer}; 2], so it can't find the correct From impl.

So my question is: can we teach rust that the array should maintain {integer} element type as long as possible, and only pick the length right away?

Josh Triplett (May 08 2020 at 20:11, on Zulip):

What would happen if you also have an instance for [i64] and [i32]?

Florian Diebold (May 08 2020 at 20:19, on Zulip):

as far as I can see, this works? I think there must be something additional going on

Lokathor (May 08 2020 at 20:19, on Zulip):

ah, my mistake, i also had impls for the unsigned types as wrll

Lokathor (May 08 2020 at 20:22, on Zulip):

@Josh Triplett if you mean &[i32] and &[i64] then currently that gives a compile error saying that the compiler doesn't know what you mean and you need to be more specific. Which seems fine to me

Lokathor (May 08 2020 at 20:27, on Zulip):

(deleted)

Lokathor (May 08 2020 at 20:29, on Zulip):

@Florian Diebold https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=6a36c8644b5033a83a84cece7022877b this demonstrates the problem, so i guess this is more like an bug in the error reporting process it goes through

Last update: Jun 05 2020 at 23:10UTC