@Alejandro Thank you for this detailed 2021 deep-dive into SE-0283's implementation challenges! Your analysis of the runtime assembly needs (especially the relative reference injection to avoid platform-specific code) and the backward compatibility headaches (stub functions/dlsym vs. hooked runtime functions) was incredibly insightful. It's clear a ton of thought went into weighing the startup costs and perf implications for mixed old/new runtime scenarios. Kudos for laying that out so clearly.
Fast-forward to November 2025: Your suggestion to wait for general conformances on non-nominal types feels spot-on, and it looks like we're closer now. Slava's 2023 pitch on User-defined tuple conformances (status: implementation in progress, feature flag TupleConformances) seems to build directly on this, enabling the runtime hooks and witness table generation that blocked SE-0283.
I've revived the discussion in my recent pitch:
[Pitch] Automatic Hashable Conformance for Tuples (Revival of SE-0283)
It focuses narrowly on Hashable (as a minimal step toward full E/C/H) to unblock common use cases like tuple dictionary keys, while preserving your concerns about safety and perf.
Questions for you or the compiler team:
- Has the
TupleConformanceswork addressed the assembly/relative ref issues (e.g., via C++-only paths)? - For backward compat, are the new runtime caches (like in iOS 15+) reducing the perf hit for apps on older targets?
- Would a scoped
Hashable-only implementation (up to arity 6) be feasible as a bridge?
I'd love your thoughts, happy to iterate or help prototype if useful. Let’s get tuples hashing!