Skip to content

Conversation

@radeusgd
Copy link
Contributor

@radeusgd radeusgd commented Jun 26, 2025

Pull Request Description

  • As discussed, we try to summarize our common understanding on expected behaviour of intersection types in various circumstances.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.

- inspecting the type via `case of`, e.g.
```
case x of
a : A -> ...
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 in this case?

Suggested change
a : A -> ...
b : B -> ...
a : A -> ...

Copy link
Member

Choose a reason for hiding this comment

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

case of patterns do not invoke conversions

```
in the first branch, the `a` has visible type `A` but the full type is still
`a : A & (hidden B)` - the `B` part is hidden, but not removed.
- dispatching a method on one of the types, e.g. calling `x.method_defined_on_A`
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it the same when calling a method defined on a hidden type? x.method_defined_on_B?

will pass the value `x` as `self` to the body of `method_defined_on_A`, the
`self` will have a visible type `A`, but the full type is still
`self : A & (hidden B)` - so the `self` value can be casted if needed.
- normally, calling conversions will 'start over' and the value returned from
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 there are conversions from both A and B to some other type? Do unhidden ones take precedence over hidden ones?

Copy link
Member

@JaroslavTulach JaroslavTulach left a comment

Choose a reason for hiding this comment

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

  • Thanks for improving the docs, Radek.
  • I prefer positive tone in the docs
  • e.g. describe how great Enso design is
  • and only then warn what would happen if it wasn't as great

the original value. E.g. `4.2 : Complex&Float : Float` is `==` and has the same
`hash` as `4.2` (in spite it _can be cast to_ `Complex`).

### TODO
Copy link
Member

Choose a reason for hiding this comment

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

What's the purpose of this TODO? If the functionality is broken, can we link to the appropriate issues?

self preserves intersection types, just hides them

That works, doesn't it?

its identity as a `Table & DB_Table` and can be uncovered via a cast or a case
expression.

It is important to ensure that various operations do not accidentally remove a
Copy link
Member

Choose a reason for hiding this comment

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

  • I don't like the term various operations
  • it only spreads FUD
  • there is no point of being so vague in the documentation
  • if you have to, move it into a "warning" or "notice" section
  • e.g. a colloquial knowledge, not part of the spec

@JaroslavTulach
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

-compiler CI: No changelog needed Do not require a changelog entry for this PR.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants