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

Func ty #942

Merged
merged 28 commits into from
Dec 7, 2023
Merged

Func ty #942

merged 28 commits into from
Dec 7, 2023

Conversation

Y-Nak
Copy link
Member

@Y-Nak Y-Nak commented Oct 16, 2023

Please start reviewing this PR after #931

This PR integrates a function definition into Fe type system.
For example,
When fn foo<T>(t: T) is defined, then foo(1i32) would conceptually be TyApp(FuncDef(foo), i32)); this representation will allow us to check all type level check (e.g., the trait bound check and a kind check) in the same way with ADT types.

The other changes are

Method Collector

The method collector collects all methods implemented for all types and performs a conflict check.
In our new type system, we can use an impl block for HKT, e.g.,

impl Option {
    pub fn foo<A>(self: Self<A>) {...}
}

Method collector reason foo method is implemented for type Option<A>, this means foo method will conflict if there is another implementation like the one below.

impl<T> Option<T> {
   pub fn foo(self) {...}
}

Trait method bound strictness check

This check verifies if the implemented method doesn't have a stricter constraint than the one that the corresponding trait method definition has.
e.g.,

trait Foo {
    fn foo<T: Clone>(self, t:  T) {}
}

impl Foo {
    // Error!
    // fn foo<T: Clone + Copy>(self, t: T) {}
    // But a weaker constraint is ok.
    fn foo<T>(self, t: T) {}
}

Trait method's argument label integrity check

This check verifies if the implemented method has the same labels as the trait method definition.
Since labels are part of the public interface of the trait, we need to ensure the same labels are used. On the other hand, argument names don't need to follow the rule.

Misc

  • Check if all the required methods are implemented
  • Check if the argument name is not duplicated
  • Check if the generic parameter is not conflicted with the parent item's generic parameter
  • Allow to specify the self type explicitly(which is necessary, especially for HKT), and check for the consistency of the self type(specified self type should start with the same type as Self).

Discussion

The current implementation tentatively allows for the function argument label to be duplicated, which is the same rule as Swift.
I think this would be useful when a function is commutative and a user wants to emphasize that property.

@Y-Nak Y-Nak force-pushed the func-ty branch 2 times, most recently from e9c2808 to 57a3493 Compare October 19, 2023 22:22
@Y-Nak Y-Nak marked this pull request as ready for review October 20, 2023 22:27
@Y-Nak Y-Nak mentioned this pull request Oct 20, 2023
3 tasks
Copy link
Collaborator

@sbillig sbillig left a comment

Choose a reason for hiding this comment

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

👍😎👍

@sbillig sbillig merged commit d664a7a into ethereum:fe-v2 Dec 7, 2023
7 checks passed
@Y-Nak Y-Nak deleted the func-ty branch May 18, 2024 20:42
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.

2 participants