SE-0395: Observability

This is not true. Several proposals have had follow-on proposals that build on them. SE-0244 (opaque result types) called out future direction of using the same syntax for arguments, later implemented in SE-0328 and SE-0341. SE-0309 (unlock existentials) called out future directions implemented in SE-0353. While not called out in the proposals, if/switch expressions came up as a future direction during SE-0255, and strongly-typed dynamic member lookup came about as a future direction discussed during SE-0195.

Lest these be dismissed with "ah, but no true future scotsman ever gets implemented" I should note that many future directions are along the lines of "this is maybe a bad idea, but this proposal doesn't rule it out" (personally I put reasync in this camp, but there are plenty of less controversial examples), or "this is a future possible direction, but meh" (SE-0268 has one of these) which are unsurprisingly unimplemented.

Other future directions are extremely complex to implement, and so are still expected but not yet here – for example, variadic generics bring us very close to generalized tuple conformances as anticipated in SE-0283, and improvements in the generics system mean we are close to getting self-conformance as anticipated by SE-0309. Others have proven too difficult after many attempts, for example, property wrapper enclosing self access (future direction of SE-0258, possibly now superseded by macros).

Where the future direction of observable types being notified they're being observed fits in this spectrum, I don't know.

One thing I do know is that the language workgroup as more than once given guidance that being against accepting a proposal purely because you want to force a future direction to be included now is not a valid issue to raise during a review. So

is not a useful position to take.

9 Likes