Skip to content
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

type "leakage" with transparent methods on opaque types #20434

Closed
erikerlandson opened this issue May 18, 2024 · 6 comments
Closed

type "leakage" with transparent methods on opaque types #20434

erikerlandson opened this issue May 18, 2024 · 6 comments
Labels
itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label

Comments

@erikerlandson
Copy link

Compiler version

3.4.2-RC1

Minimized code

opaque type Repro = Int
object Repro:
    extension(v: Int)
        // lift raw Int
        inline def asRepro: Repro = v
    extension(r: Repro)
        // this doesn't need to be transparent but my actual
        // use case does
        transparent inline def *(rr: Repro): Repro =
            r * rr

object repro:
    import Repro.asRepro
    val x = 2.asRepro
    // this "leaks" the type 'Int'
    val y: (Repro & Int) = x * x
    // this should fail but doesn't
    val z = 1 + y

Output

The * method returns type Repro & Int, due to transparent keyword. In other words, it leaks the implementation type Int

Expectation

I need a way for transparent methods to return only Repro, not Repro & Int, to prevent leaky abstraction of the opaque type.

@erikerlandson erikerlandson added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels May 18, 2024
@tschuchortdev
Copy link

Possible duplicate: #20302

@erikerlandson
Copy link
Author

@tschuchortdev agree, that looks like the same problem

@soronpo
Copy link
Contributor

soronpo commented May 21, 2024

Also see #13461

@erikerlandson
Copy link
Author

@soronpo it worries me a little this bug is 3 years old 😂 Is it fixable? If it's not something likely to be fixed in the near term, I will probably decide to deploy some alternative approaches that are less aesthetically pleasing but maintain proper typing

@soronpo
Copy link
Contributor

soronpo commented May 22, 2024

I don't know the likeliness of it being fixed. I do wish we had more emphasis on stability in Scala 3.

@erikerlandson
Copy link
Author

I just tried removing transparent on my methods, and the dependent types seem to be resolving fine without it. It looks like scala 3 is an improvement here over scala 2.

Since this is working for me, I'll close this issue, although it still seems like a typing problem if you really did need transparent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label
Projects
None yet
Development

No branches or pull requests

3 participants