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

Convert SAM result types to function types #17740

Merged
merged 3 commits into from
Jun 18, 2023
Merged

Conversation

dwijnand
Copy link
Member

No description provided.

Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a definite improvement, but it would be great if we could give some thought to the case where the method is ParamDependent.

case SAMType(mt @ MethodTpe(_, formals, restpe)) =>
case pt1 @ SAMType(mt @ MethodTpe(_, formals, methResType)) =>
val restpe = methResType match
case mt: MethodType if !mt.isParamDependent => mt.toFunctionType(isJava = pt1.classSymbol.is(JavaDefined))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if mt is ParamDependent? Can we still get a crash then?

Maybe we should in that case fall back to the default composition with wildcard types?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried and I think if you make it param dependent it doesn't qualify as a SAM type? I guess it'll be good to have a case in, just to prove it doesn't crash the compiler - and that way you can review that I've written the test case correctly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried and I think if you make it param dependent it doesn't qualify as a SAM type?

I doubt that. Types with ParamDependent method types cannot be SAM types. But I don't see that ParamDependent result types are excluded.

@odersky odersky assigned dwijnand and unassigned odersky Jun 4, 2023
In decomposeProtoFunction I wanted to reuse WithFunctionType by running
toFunctionType on the whole SAM and then dropping the first parameters.
But with result dependent functions that results in a refined type,
which is composed of:
  * the function with a result that is a non-depedent approximation
  * the original, non-function, method type

So I went back to calling toFunctionType on the method result type
specifically, like it used to be.

Which means I stopped using the SAMType.WithFunctionType extract, so I
merged it with its remaining usage with subtype checking and called the
SAMType.isSamCompatible.
@dwijnand dwijnand assigned odersky and unassigned dwijnand Jun 18, 2023
@dwijnand dwijnand merged commit 9b70af9 into scala:main Jun 18, 2023
17 checks passed
@dwijnand dwijnand deleted the using-sam branch June 18, 2023 08:31
smarter added a commit to dotty-staging/dotty that referenced this pull request Jun 30, 2023
This reverts most of scala#17740 and instead add a check on currying in SAMType. We
could consider allowing curried methods in SAM types, but this would be a
language change that requires a SIP, and the implementation would need an
adaptation step in erasure since the invokedynamic method needs to have a
compatible signature with the abstract method in the trait.
smarter added a commit to dotty-staging/dotty that referenced this pull request Jun 30, 2023
This reverts most of scala#17740 and instead add a check on currying in SAMType. We
could consider allowing curried methods in SAM types, but this would be a
language change that requires a SIP, and the implementation would need an
adaptation step in erasure since the invokedynamic method needs to have a
compatible signature with the abstract method in the trait.
smarter added a commit to dotty-staging/dotty that referenced this pull request Jul 5, 2023
This reverts most of scala#17740 and instead add a check on currying in SAMType. We
could consider allowing curried methods in SAM types, but this would be a
language change that requires a SIP, and the implementation would need an
adaptation step in erasure since the invokedynamic method needs to have a
compatible signature with the abstract method in the trait.
smarter added a commit to dotty-staging/dotty that referenced this pull request Jul 5, 2023
This reverts most of scala#17740 and instead add a check on currying in SAMType. We
could consider allowing curried methods in SAM types, but this would be a
language change that requires a SIP, and the implementation would need an
adaptation step in erasure since the invokedynamic method needs to have a
compatible signature with the abstract method in the trait.
smarter added a commit that referenced this pull request Jul 5, 2023
This reverts most of #17740 and instead add a check on currying in
SAMType. We could consider allowing curried methods in SAM types, but
this would be a language change that requires a SIP, and the
implementation would need an adaptation step in erasure since the
invokedynamic method needs to have a compatible signature with the
abstract method in the trait.
@Kordyjan Kordyjan added this to the 3.4.0 milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants