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

Adding my comments to Intersection Types documentation #11838

Conversation

radeusgd
Copy link
Member

Pull Request Description

Important Notes

Checklist

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

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    TypeScript,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • Unit tests have been written where possible.
  • If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
    or the Snowflake database integration, a run of the Extra Tests has been scheduled.
    • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

@radeusgd radeusgd added the CI: No changelog needed Do not require a changelog entry for this PR. label Dec 11, 2024
@radeusgd radeusgd mentioned this pull request Dec 11, 2024
4 tasks
Comment on lines +87 to +99
> [!WARNING]
> Keep in mind that while both argument type check in method definitions and a
> 'type asserting' expression look similarly, they have slightly different behaviour.
> ```
> f a:Float = a
> g a = a:Float
> ```
> These two functions, while very similar, will have different behaviour when
> passed a value like the value `c` above. The function `f` will fail with
> a type error, because the visible type of `c` is just `Complex` (assuming
> the conversion to `Float` is not available in the current scope).
> However, the function `g` will accept the same value and return it as
> a `Float` value, based on the 'hidden' part of its type.
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 want to make it clear that while the syntax is very similar, the checked argument and type-asserting expressions are actually different and behave differently in regard to the 'hidden' types.

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.

Accepted most of your changes in d1cbc8d

> used to create the intersection type is not available in the default
> conversion resolution scope. Thus it cannot be defined in the same module
> as `Complex` or `Float` types, but instead it should be defined in a separate
> module that is only imported in the place that will be constructing the multi-values.
Copy link
Member

Choose a reason for hiding this comment

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

That's correct and exactly as prototyped in the tests.

- or inspect the types in a `case` expression, e.g.
```
case c of
f : Float -> f.sqrt
Copy link
Member

Choose a reason for hiding this comment

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

@JaroslavTulach
Copy link
Member

Accepted as d1cbc8d

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

2 participants