Pre-RFC improved ergonomics for `!`

Thanks both. Short answer: I'm checking in on how desirable this is before investing loads of effort in getting it to actually work. I do have an idea though - see below.

zackw:

I'm pretty sure you meant to have a section explaining this, since the "this won't work because ..." section is responding to critics of your proposal; did you accidentally cut it when editing?

Didn't cut as much as decided to focus first on assessing the overall wider desirability of such a feature.

Working out the best feasible approach (or admitting here isn't one) will be a chunk of effort on my part which I'm happy to invest if the overall proposal doesn't fall flat with "no-one really cares about this much".

Once I do that then I can flesh out the Guide-Level explanation & reference implementation and run another feedback loop looking at whether it's considered viable & sustainable by the lang team (as this would likely need a longer period before stabilising so it'll boil down to how complex the actual changes are vs. how valuable vs. how they feel about trusting a person they don't yet know who says they'll look after this through that period)

robofinch:

MusicalNinjaDad:

Or rather, the implicit conversion will only take effect if it is safe to do so.

How is this determined?

My current thinking is:

1. Leverage (and minimally extend?) the existing check functions in the MIR to effectively validate whether implementing one of the workarounds for the Option example is safe - I'd experiment starting with those that run when creating map for the Foo that has a generic !
2. In order of preference (again I need to experiment and research to see what is actually feasible):
   • Leverage (and minimally extend?) the existing coercion & fallback functionality, still at MIR.
   • implement a dummy version of the validated workaround in the MIR.
   • Look at leveraging generics monomorphisation to generate the required variations (if that's needed then this had better be very desirable as it would be much further down the compiler stack and risk binary-bloat. I'd guess the idea gets killed if it turns out this is the solution).

What I've seen of the compiler code while looking into this topic so far makes me feel like this has some chance of success. Enough that I'm willing to invest a chunk of my time playing around to see.