-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Top-level definitions using opaque types can bypass their opacity #8175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
In fact, opaque types are transparent in the scope they appear, not just in their companion object. I have added a section to the docs that explains this. |
Got it. Might we consider a mechanism to make this property known to users at compile-time? Something like
|
TIL I don't understand what "scope" means. I thought it meant literally what is "seen". So I would have said that this disposition is at odds with #7891 But scope does not mean the same thing as telescope or kaleidoscope. It means a target to aim at (skopos). The figurative sense is that the scope of one's power includes all the targets one can hit. Shakespeare: "Desiring this mans art, and that mans skope." (Sonnet 29, in which he is depressed about his prospects, then gets a mood adjustment from his lover.) I would still prefer that scope is what I can tell by looking. Except, of course, for implicit scope. "Opaque" means obscure because it's in shadow. It's too bad we can't use opaque for shadowed symbols. The sense of "not translucent" comes afterward, from optical science. OED has another nice line from Spenser: "slipper hope Of mortal men, that swincke and sweate for nought, And shooting wide, doe misse the marked scope." There is an old word "swinch" for "toil", which someone may want to use for their latest Scala project. |
@ryanberckmans In my experience it is really hard to do something like what you propose without producing false negatives or annoying warnings. |
Fix #8175: Explain transparency of toplevel opaque types
minimized code
https://scastie.scala-lang.org/60nHfRoiRVONgdxGJpUjZA
expectation
As shown in the Scastie snippet, this definition
Is expected to fail compilation with the error
Found: Bar => String, Required: Foo => String
but instead compilation succeeds if the definition is top-level.The text was updated successfully, but these errors were encountered: