Triage for two T-lang issues

[nikomatsakis]

While going over nominated issues, I encountered two that I had trouble categorizing:

• https://github.com/rust-lang/rust/issues/25692

The problem here is mostly that for a type like [T] to be considered “well-formed”, we do not require that T: Sized, which permits types like [[T]] that are not currently resolvable. This is bad because we accept things we probably should not, but on the other hand there isn’t much you can do with these types, so the risk of real problems seems low. This feels related to arielb1’s PR https://github.com/rust-lang/rust/pull/25701 as well, which merits a separate discussion thread. I opted for medium priority since I’m not sure how people will come to depend on this. But we should address the overall issue ASAP nonetheless.

• https://github.com/rust-lang/rust/issues/25658

The problem here is a hole in macro forward compatibility. If we are going to fix this, it feels like we should do it ASAP, because I can easily imagine people coming to rely on it. Thus I assigned it P-high (at least to make a decision).

Thoughts?

[huon]

• https://github.com/rust-lang/rust/issues/25692

Is it possible to write any non-trivial code that handles a [[T]]? It seems like essentially everything (indexing etc.) wouldn’t work. That said, I suppose one might construct/use it via unsafe code, but it seems like all such cases would be better handled with a raw pointer or with just [T]. I’m happy with medium.

• https://github.com/rust-lang/rust/issues/25658

High sounds good. Pending a crater report, I’m happy for an error, or even a warning that becomes an error.

[aturon]

I agree with both of the calls made here.

[llogiq]

For what it’s worth, my RFC PR #1147, while currently leaving out language evolution, could well be extended to also contain it if there is interest.

The gist of it is that we would need to keep both the old and new code paths and have the user decide which version they want by specifying a per-crate target version.

Alas, making incompatible language changes depend on this is currently not feasible because we don’t have pervasive target version declarations, but once they are the norm, it could be possible to have breaking language changes without breaking builds, thus leaving us much more leeway in implementing changes like this.

[nikomatsakis]

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