user defined const param type backcompat

[lcnr]

allowing a type to be used as a const parameter type adds some additional backcompat concerns.

For example adding raw/function pointer fields is suddenly a breaking change because the type stops being structural match.

How do we want to deal with this? Require the user to explicitly opt in, require all fields to be public (disqualifies NonZeroT), or something else?

[oli-obk]

We already have such behaviour for Send and Sync. So users already know that adding such fields can be breaking changes. I think as long as we aren't worse in UX than Send and Sync, this is fine?

[lcnr]

hm, I guess I am a bit concerned because that interaction is a lot less obvious as I think many types aren't be intended to be used as const params. If there's a good way to avoid these issues I would prefer doing so.

[BoxyUwU]

When you add a ptr to your struct you can also:

unsafe impl (Send/Sync) for Foo

but that's not an option with this I think

[oli-obk]

we could add an additional derive(StructuralMatch) requirement for any types used as const generics.

[varkor]

I'm surprised I can't find previous discussion on this topic: this is presumably a problem for anything involving structural equality, not just const generics. Having a new marker trait seems like the only plausible solution here.

[lcnr]

had some further discussion about this on zulip: https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/meeting.202021-03-02/near/228441502

The consensus seems to be that we want to add an additional trait to opt into allowing types as const parameters as proposed in #6 (comment)

Still open is how exactly this interacts with structural match, it probably makes sense to try and get some conclusions from rust-lang/rust#74446. Maybe we can try and summarize the current status there and then talk about the remaining questions in a sync meeting?

[lcnr]

closing this after summarizing the results in #34