odersky

> I was thinking whether it is possible to handle it in base type computation logic? Conceptually, it seems to be the same problem as refining types of members with...

This PR now bundles three improvements to modularity, all available under the `experimental.modularity` language import: - tracked type parameters - refinements in class parents - non-final type export forwarders The...

`refined` works on the class, but not on the parameter (and we need it to work on the parameter, in the end). `dependent` is too much type theory jargon, it...

Needs minor release since it introduces a new Tasty tag.

This is part of #20061

I think a warning would be counter-productive because everytime someone needs to write an identifier like this there would be a spurious warning. And @nowarn is a crutch. Put in...

Can we get a minimization of this? I

No, I think we have to change the mindset of people instead. Breaks are aborts and there should be only one kind of abort. And everytime I see a "just...

I think we should try make it a linter warning if 1. We catch something that is a possible supertype of BreakException 2. We have a boundary.Label in scope 3....

We went over this at length before. Yes, we certainly do want `Try` to catch a break abort. If we don't do that we risk deadlocks in code that uses...