Replies: 4 comments
-
|
The core design of MoonBit is structural trait, i.e. if you have methods that fulfills a trait then you implements a trait. Changing it to nominal trait would mean having a completely new programming language. Is there any specific cases that you can provide where you encounter any inconveniences? |
Beta Was this translation helpful? Give feedback.
-
will there be sufficient LSP support? for example, a table at type definitions that can be used to jump to the implementation methods, or a way to get hints about which methods have not yet been implemented when implementing a trait for a specific type? |
Beta Was this translation helpful? Give feedback.
-
|
Feature request noted. We'll try to improve the tooling. |
Beta Was this translation helpful? Give feedback.
-
|
to keep issues small only for bug reports, for general discussions, https://github.com/moonbitlang/core/discussions is welcome |
Beta Was this translation helpful? Give feedback.
-
Summary
To implement a trait for a type, it must use syntax like
impl Trait for Type ...to specify it.Motivation
To prevent unintended trait implementations and facilitate searching for a type's trait implementations.
Detailed Design
Always require a
impl Trait for Type ...block when implementing trait.Drawbacks
A programming language like Rust, which implements this feature, requires a complex trait solver and has encountered several bugs related to subtyping in lifetimes. Moonbit, without lifetimes, might not require such a complex implementation. However, adding this feature to Moonbit could still increase compiler complexity and reduce compilation speed.
Alternatives
For unintended trait implementations, Moonbit may require that type is not implemented for specific traits.
For searching implementations, hoping LSP of Moonbit could solve this erogonomic issue.
Beta Was this translation helpful? Give feedback.
All reactions