You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've ended up with a somewhat inconsistent syntax for stating that a class versus an interface implements an interface internally / externally:
class C {
// Internal implementation
impl as X;
// External implementation
external impl as X;
}
interface D {
// Internal implementation
extends X;
// External implementation
impl as X;
}
As well as being a little inconsistent between classes and interfaces, it also results in excess verbosity for impls at the top level, where the external keyword is always required in order to make those declarations consistent with ones at class scope.
I think there's an alternative here that we've not considered: use the interface approach in classes too:
class C {
// Internal implementation
extends X {
// ...
}
// External implementation
impl as X {
// ...
}
}
In the case of a separate declaration and definition of the implementation, I think it'd be least surprising to use the following syntax:
class C {
extends X;
}
// Not `extends C as X { ... }`
impl C as X { ... }
More broadly, I wouldn't allow extends to specify an "implementing type" at all -- it would always be Self. This would disallow conditional conformance with an internal impl, such as in this example from the design:
class X(T:! Type) {
impl X(i32) as Foo {
fn F[me: Self]();
}
impl X(i64) as Bar {
// ❌ Illegal: name conflict between `Foo.F` and `Bar.F`
fn F[me: Self](n: i64);
}
}
... for which neither impl would be expressible any more. I think that's reasonable: saying that the interface of a generic class contains member names from an impl for a special case of that generic class seems likely to be confusing. Conditional conformance would still be possible, but only for external implementations.
The text was updated successfully, but these errors were encountered:
zygoloid
added
the
design idea
An issue recording a specific language design idea that folks can potentially pick up.
label
Oct 15, 2022
We've ended up with a somewhat inconsistent syntax for stating that a class versus an interface implements an interface internally / externally:
As well as being a little inconsistent between classes and interfaces, it also results in excess verbosity for impls at the top level, where the
external
keyword is always required in order to make those declarations consistent with ones at class scope.I think there's an alternative here that we've not considered: use the
interface
approach in classes too:In the case of a separate declaration and definition of the implementation, I think it'd be least surprising to use the following syntax:
More broadly, I wouldn't allow
extends
to specify an "implementing type" at all -- it would always beSelf
. This would disallow conditional conformance with an internal impl, such as in this example from the design:... for which neither
impl
would be expressible any more. I think that's reasonable: saying that the interface of a generic class contains member names from an impl for a special case of that generic class seems likely to be confusing. Conditional conformance would still be possible, but only for external implementations.The text was updated successfully, but these errors were encountered: