Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Implement revised coercion rules #18469

Closed
aturon opened this issue Oct 30, 2014 · 22 comments
Closed

Implement revised coercion rules #18469

aturon opened this issue Oct 30, 2014 · 22 comments
Assignees
@nrc
Labels
A-coercions Area: implicit and explicit `expr as Type` coercions B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. P-medium Medium priority S-tracking-impl-incomplete Status: The implementation is incomplete. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented Oct 30, 2014

Tracking issue for RFC 401.
@aturon aturon mentioned this issue Oct 30, 2014
Merged
@aturon aturon added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. I-nominated labels Oct 30, 2014
@aturon
Copy link
Member Author

aturon commented Oct 30, 2014

Nominating: this contains backwards-incompatible changes.

For triage purposes, we probably want to pull out the DST coercions part of this as P-High.

@nrc
Copy link
Member

nrc commented Nov 4, 2014 •
edited by crlf0710
Loading

Summary of changes to make from the RFC:

We should double check that these changes actually get us to the right destination as defined by the RFC.

I filed bugs for the larger pieces of work, the rest are pretty minor and can be tracked here. Those marked with an asterisk are backwards incompatible.

This was referenced Nov 4, 2014
Open
Closed
Closed
Closed
Closed
@nrc nrc self-assigned this Nov 4, 2014
@nrc
Copy link
Member

nrc commented Nov 4, 2014

Assigning myself for misc back-compat parts of this, I don't intend to do the rest right now.

@nrc nrc mentioned this issue Nov 5, 2014
Closed
@pnkfelix
Copy link
Member

pnkfelix commented Nov 6, 2014

Assigning P-backcompat-lang, 1.0.

@pnkfelix pnkfelix added this to the 1.0 milestone Nov 6, 2014
This was referenced Dec 12, 2014
Merged
Merged
nrc added a commit to nrc/rust that referenced this issue Dec 16, 2014
@nrc
Remove the double auto-ref on arrays/strings as receivers
769aa0a 
Part of rust-lang#18469

[breaking-change]

A receiver will only ever get a single auto-reference. Previously arrays and strings would get two, e.g., [T] would be auto-ref'ed to &&[T]. This is usually apparent when a trait is implemented for `&[T]` and has a method takes self by reference. The usual solution is to implement the trait for `[T]` (the DST form).
bors added a commit that referenced this issue Dec 17, 2014
@bors
auto merge of #19761 : nick29581/rust/coerce-double, r=nikomatsakis
4265e86 
Part of #18469

[breaking-change]

A receiver will only ever get a single auto-reference. Previously arrays and strings would get two, e.g., [T] would be auto-ref'ed to &&[T]. This is usually apparent when a trait is implemented for `&[T]` and has a method takes self by reference. The usual solution is to implement the trait for `[T]` (the DST form).

r? @nikomatsakis (or anyone else, really)
@aturon
Copy link
Member Author

aturon commented Jan 5, 2015

@nick29581 Are the back-compat parts done? If so, let's re-nominate.

@nrc nrc added the I-nominated label Jan 5, 2015
@nrc
Copy link
Member

nrc commented Jan 5, 2015

Yep, should no longer block

@pnkfelix
Copy link
Member

pnkfelix commented Jan 8, 2015

No more back incompat stuff; just usability issues. P-high.

@pnkfelix pnkfelix added P-medium Medium priority and removed P-backcompat-lang labels Jan 8, 2015
@pnkfelix pnkfelix removed this from the 1.0 milestone Jan 8, 2015
@alexcrichton alexcrichton added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Aug 11, 2015
@brson
Copy link
Contributor

brson commented Jul 14, 2016 •
edited by alexcrichton
Loading

Triage: ancient RFC tracking bug slipping through the cracks cc @rust-lang/lang what's up?

@nrc
Copy link
Member

nrc commented Jul 14, 2016

Discussed at the lang meeting. I will go through the checklist to make sure it is up to date. We think it should remain p-medium since periodic check ins will be worthwhile.

@nrc nrc removed the I-nominated label Jul 14, 2016
@petrochenkov petrochenkov mentioned this issue Nov 1, 2016
Merged
@qnighy
Copy link
Contributor

qnighy commented Jun 4, 2017

Looking through rust-lang/rfcs#401, #37685, #32702, #34451, and this, it seems that tuple DSTs and their coercion should be allowed but the coercion is not implemented. Am I right?

@nikomatsakis
Copy link
Contributor

@qnighy I think that is correct. I'm not sure just how much implementation work would be needed, there may be random bits of the compiler that need to be updated scattered around.

@qnighy
Copy link
Contributor

qnighy commented Jun 7, 2017

@nikomatsakis Thank you. I'm working on it.

@qnighy
Copy link
Contributor

qnighy commented Jun 7, 2017

Another question: PartialEq, Eq, PartialOrd, Ord, Debug, Hash can be generalized to unsized tuples. Are there any RFCs referring to this possibility?

@qnighy qnighy mentioned this issue Jun 8, 2017
Merged
@nikomatsakis
Copy link
Contributor

@qnighy not that I'm aware of; I don't think we necessarily need an RFC for such a thing though

@qnighy qnighy mentioned this issue Jun 24, 2017
Open
bors added a commit that referenced this issue Jun 29, 2017
@bors
Auto merge of #42527 - qnighy:unsized-tuple-coercions, r=arielb1
686ec28 
Unsized tuple coercions

Part of #18469. Fixes #32702.

#37685 and #34451 might also be related.

This PR does the following:

- Introduce explicit `Sized` constraints on tuple initializers, similar to that of record-struct initializers. Not much relevant to the main contribution but I noticed this when making tests for unsized tuple coercions.
- Implement `(.., T): Unsize<(.., U)>` where `T: Unsize<U>`.
- Assume `(.., T)` is MaybeUnsizedUnivariant.
- Modify `src/librustc/ty/util.rs` and `src/librustc_trans/glue.rs` so that tuples and structs are uniformly traversed when translating.
@qnighy qnighy mentioned this issue Jul 2, 2017
Merged
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jul 12, 2017
@Mark-Simulacrum
Rollup merge of rust-lang#43011 - qnighy:unsized-tuple-impls, r=aturon
e5288c9 
Implement Eq/Hash/Debug etc. for unsized tuples.

As I mentioned in [the comment in rust-lang#18469](rust-lang#18469 (comment)), the implementations of `PartialEq`, `Eq`, `PartialOrd`, `Ord`, `Debug`, `Hash` can be generalized to unsized tuples.

This is consistent with the `derive` behavior for unsized structs.

```rust
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Debug, Default, Hash)]
struct MyTuple<X, Y, Z: ?Sized>(X, Y, Z);

fn f(x: &MyTuple<i32, i32, [i32]>) {
    x == x;
    x < x;
    println!("{:?}", x);
}
```

Questions:

- Need an RFC?
- Need a feature gate? I don't think it does because the unsized tuple coercion rust-lang#42527 is feature-gated.
- I changed `builder.field($name);` into `builder.field(&$name);` in the `Debug` implementation to pass compilation. This won't affect the behavior because `Debug for &'a T` is a mere redirection to `Debug for T`. However, I don't know if it affects code size / performance.
@Mark-Simulacrum Mark-Simulacrum added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jul 22, 2017
@torkleyy
Copy link

Can I use any workaround until this is resolved? I have a custom type that I want to convert from Foo<[u32; 10]> to Foo<[u32]>. I could write a method which replaces the PhantomData, but I want it to work for all Unsize-able types.

@eddyb
Copy link
Member

eddyb commented Nov 14, 2018

cc @rust-lang/lang Do we want to close this and all the unfinished sub-issues, and require a new RFC for any new features in this area, even if the old RFC covers them?
One thing to note is that we should probably not implement any new coercions until we get a new system built on top of traits and/or chalk, that can handle arbitrary library opt-in.

@Centril
Copy link
Contributor

Centril commented Dec 1, 2018

@eddyb What exactly remains to be done here; could you clarify the unfinished sub-issues?

@eddyb
Copy link
Member

eddyb commented Dec 2, 2018

@Centril I'm just referring to this comment #18469 (comment) and the unchecked checkboxes in it.

@jonas-schievink jonas-schievink added the A-coercions Area: implicit and explicit `expr as Type` coercions label Aug 5, 2019
@thanatos thanatos mentioned this issue Sep 14, 2020
Open
@joshtriplett joshtriplett added the S-tracking-impl-incomplete Status: The implementation is incomplete. label Nov 10, 2021
@oconnor663 oconnor663 mentioned this issue Oct 19, 2022
Open
@nikomatsakis
Copy link
Contributor

Closing this issue -- anything from RFC 401 that isn't already implemented probably requires a fresh RFC by now, or should at least have its own issue.

@workingjubilee workingjubilee mentioned this issue May 4, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nrc nrc

Labels
A-coercions Area: implicit and explicit `expr as Type` coercions B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. P-medium Medium priority S-tracking-impl-incomplete Status: The implementation is incomplete. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests