Skip to content

Consider aliases of Any as top #19735

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

Closed
wants to merge 1 commit into from
Closed

Conversation

dwijnand
Copy link
Member

Fixes #19610

@odersky
Copy link
Contributor

odersky commented Feb 24, 2024

This is kind of dangerous. We previously took [T <: Any] as an approximation of [T] since that's the best we can do. But now, if type Alias = Any we also treat [T <: Alias] as "having no upper bound", which is patently untrue.

@dwijnand
Copy link
Member Author

dwijnand commented Feb 24, 2024

I feel like we should sway one side or the other, not this in-between, where [T] and [T <: Any] are the same but, [T <: Any] and [T <: Alias] aren't. Maybe upper bound should be Option[Type] 😀

Edit: Actually, why don't we use NoType to differentiate between [T] and [T <: Any]... 🤔

@odersky
Copy link
Contributor

odersky commented Feb 24, 2024

It does not matter what the precise rules are, as long as we stick to them.

@dwijnand
Copy link
Member Author

I think "aliases shouldn't affect typing" is a rule we obey. I'm not sure if it's a rule for type inference too, but I think it should be. By "stick to them" do you mean don't touch how inference works or am I interpreting too broadly?

@odersky
Copy link
Contributor

odersky commented Feb 24, 2024

Yes, the fact whether something has a bound or not is used in several critical pieces of type inference. We should not change that definition.

@dwijnand dwijnand closed this Feb 24, 2024
@dwijnand dwijnand deleted the alias-top-is-top branch February 24, 2024 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Excessively loose type inference
2 participants