{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihiecjihvk52auvh55mqseratohyukskgtlcmp6ssfj6fouyvyhla",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mikwsyg66bl2"
  },
  "path": "/t/yet-another-half-baked-idea-for-working-around-the-orphan-rule/24121#post_9",
  "publishedAt": "2026-04-02T10:23:17.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[Pre-RFC] Scoped `impl Trait for Type` - #20 by Tamschi",
    "[1]",
    "↩︎"
  ],
  "textContent": "This maybe?: [Pre-RFC] Scoped `impl Trait for Type` - #20 by Tamschi\n\nProbably not exactly what you were referring to since that specifies anonymous module-addressed implementations (which is helpful for subsetting generic implementations in that RFC). It's in principle very similar to what was proposed here, though, at least in terms of type system interactions, and discusses _afaik_ all the edge cases that have come up over time.\n\nThe main formal issue that proposals like this run into is that _currently_ you can make `unsafe` assumptions about bounds-linked implementations, which makes solutions like this either:\n\na) unsound,\nb) make implementation of traits a SemVer hazard in general or\nc) introduce more friction (require `unsafe`) to reuse of global implementations in those combinations.\n\nI went with[1] c) in my RFC (`unsafe use ::{impl Trait for Type};` to allow it consumer-side, and/or a boolean attribute `impl`-side), but considering how much of a niche case that likely is in practice, _I still think it would be sensible to flip the default for whether a global`impl Trait for Type` can safely be combined with non-global `impl`s elsewhere as part of an edition._\n\n(There are also \"soft\" issues related to friction at crate APIs, though I think a proposal that distinguishes types **and** is always explicit, like this one here, should have fewer of those.)\n\n* * *\n\n  1. I _still_ haven't gotten around to actually revising the RFC with this fix properly, but it's outlines fairly unambiguously in the GitHub comments at least  ↩︎\n\n\n",
  "title": "Yet another half-baked idea for working around the orphan rule"
}