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

Change representation of retains annotation? #22842

Open
odersky opened this issue Mar 20, 2025 · 0 comments · May be fixed by #22909
Open

Change representation of retains annotation? #22842

odersky opened this issue Mar 20, 2025 · 0 comments · May be fixed by #22909
Assignees
Labels
area:annotations area:experimental:cc Capture checking related itype:language enhancement itype:question stat:needs decision Some aspects of this issue need a decision from the maintainance team.

Comments

@odersky
Copy link
Contributor

odersky commented Mar 20, 2025

The current definition of the internal @retains annotation is this one:

/** An annotation that indicates capture of a set of references under -Ycc.
 *
 *      T @retains(x, y, z)
 *
 *  is the internal representation used for the capturing type
 *
 *      T ^ {x, y, z}
 *
 *  The annotation can also be written explicitly if one wants to avoid the
 *  non-standard capturing type syntax.
 */
@experimental
class retains(xs: (Any@retainsArg)*) extends annotation.StaticAnnotation

I wonder whether it would not be better to define it differently:

class retains[C] extends annotation.StaticAnnotation

Here, C would be a type representing a capture set. Since we don't have sets in Tasty, we can represent it as a union type. For instance,

T ^ {x, y.rd, z*, X} 

would be represented as

T @retains[
    x.type 
  | y.type @readOnlyCapability 
  | z.type @reachCapability
  | X]

In other words, it's exactly the representation we use for capture sets, but as a union type.

Advantages:

  • No need to convert to and from an intermediate representation.
  • More compact representation since we do not need trees
  • Possibility to better hash those annotated types. I noted that in larger projects we create a huge number of @retains-annotated types because trees use identity hash codes.

Downsides:

  • We lose positions for error reporting. The most common errors would be "x cannot be tracked since its capture set is empty". Or "x is redundant because it is subsumed by y`". In both cases we can only underline the whole annotation, not the specific capability.
  • ?
@odersky odersky added the stat:needs triage Every issue needs to have an "area" and "itype" label label Mar 20, 2025
@Gedochao Gedochao added itype:question itype:language enhancement area:annotations stat:needs decision Some aspects of this issue need a decision from the maintainance team. and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Mar 20, 2025
@natsukagami natsukagami added the area:experimental:cc Capture checking related label Mar 21, 2025
@noti0na1 noti0na1 self-assigned this Mar 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:annotations area:experimental:cc Capture checking related itype:language enhancement itype:question stat:needs decision Some aspects of this issue need a decision from the maintainance team.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants