From adb1131d08f28f0bc5f729e88b73cf22846c86c5 Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Fri, 5 Feb 2021 09:01:36 -0800 Subject: Initial implementation of interface conjunctions (#1691) The basic feature here is the ability to use the `&` operator to produce the conjunction/intersection of two interfaces. That is, you can have interfaces: interface IFirst { int getFirst(); } interface ISecond { int getSecoond(); } and if you need a generic function where the type parameter `T` must conform to *both* of these interfaces, you express that by constraining the parameter to the intersection of the interfaces: void someFunction(T value) { ... } Without this feature, the main alternative an application would have is to define an intermediate interface, like: interface IBoth : IFirst, ISecond {} Forcing users to deal with an intermediate interface creates more work for type authors (they need to remember to inherit from the right combined interface(s)), or for `extension` authors (when you add `ISecond` to a type that used to just support `IFirst`, you had better also add `IBoth`). In the worst case, a family of N related "leaf" interfaces would give rise to an exponential number of intermediate interfaces to represnt the possible combinations. A conjunction like `IFirst & ISecond` is officially its own type, and can be used to declare a type alias: typealias IBoth = IFirst & ISecond; This change only includes the first pass of work on this feature, so there are several caveats to be aware of: * Using a conjunction as part of an inheritance clause is not yet supported (e.g., `struct X : IFirst & ISecond`). This is true even if the conjunction was introduced by an intermediate `typealias` * The `&` syntax introduced here is only parsed in places where only a type (not an expression) is possible. This means you cannot do things like cast to a conjunction with `(IFirst & ISecond)(someValue)`. * This work *should* apply to conjunctions of more than two interfaces (like `IA & IB & IC`) but that has not yet been tested * In the long run it may be sensible to allow conjunctions that use concrete types, but we really ought to have the semantic checking logic rule that out for now. * During testing, I encountered compiler crashes when trying to use this feature together with `property` declarations. Further investigation and debugging is called for. * The handling of conjunction types is currently incomplete, in that there are many equivalences the compiler does not yet understand. For example, it is clear that `IA & IB` is equivalent to `IB & IA`, but the compiler currently does not understand this and will treat them as different types. A deeper implementation approach is called for. * Conjunctions are currently only supported for generic type parameter constraints, when performing full specialization. Use of conjunctions for existential-type value parameters or with dynamic dispatch is not yet supported. --- source/slang/slang-ast-type.cpp | 93 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 93 insertions(+) (limited to 'source/slang/slang-ast-type.cpp') diff --git a/source/slang/slang-ast-type.cpp b/source/slang/slang-ast-type.cpp index 9c00c13ba..79df8e48b 100644 --- a/source/slang/slang-ast-type.cpp +++ b/source/slang/slang-ast-type.cpp @@ -938,5 +938,98 @@ Val* ThisType::_substituteImplOverride(ASTBuilder* astBuilder, SubstitutionSet s return substType; } +// !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! AndType !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! + +String AndType::_toStringOverride() +{ + String result; + result.append(left->toString()); + result.append(" & "); + result.append(right->toString()); + return result; +} + +bool AndType::_equalsImplOverride(Type * type) +{ + auto other = as(type); + if (!other) + return false; + + if(!left->equals(other->left)) + return false; + if(!right->equals(other->right)) + return false; + + return true; +} + +HashCode AndType::_getHashCodeOverride() +{ + Hasher hasher; + hasher.hashObject(left); + hasher.hashObject(right); + return hasher.getResult(); +} + +Type* AndType::_createCanonicalTypeOverride() +{ + AndType* canType = m_astBuilder->create(); + + // TODO: proper canonicalization of an `&` type relies on + // several different things: + // + // * We need to re-associate types that might involve + // nesting of `&`, such as `(A & B) & (C & D)`, into + // a canonical form where the nesting is consistent + // (i.e., always left- or right-associative). + // + // * We need to commute types so that they are in a + // consistent order, so that `A & B` and `B & A` both + // result in the same canonicalization. This requirement + // implies that we must invent a total order on types. + // + // * We need to canonicalize `&` types where one of the + // elements might be implied by another. E.g., if we + // have `interface IDerived : IBase`, then a type like + // `IDerived & IBase` is equivalent to just `IDerived` + // because the presence of an `IBase` conformance is + // implied. A special case of the above is the possibility + // of duplicates in the list of types (e.g., `A & B & A`). + // + // * The previous requirement raises the problem that + // the relationships between `interface`s might either + // evolve over time, or be subject to `extension` + // declarations in other modules. The canonicalization + // algorithm must be clear about what information it + // is allowed to make use of, as this can/will affect + // binary interfaces (via mangled names). + // + // We are going to completely ignore these issues for + // right now, in the name of getting something up and running. + // + canType->left = left->getCanonicalType(); + canType->right = right->getCanonicalType(); + + return canType; +} + +Val* AndType::_substituteImplOverride(ASTBuilder* astBuilder, SubstitutionSet subst, int* ioDiff) +{ + int diff = 0; + + auto substLeft = as(left ->substituteImpl(astBuilder, subst, &diff)); + auto substRight = as(right->substituteImpl(astBuilder, subst, &diff)); + + if(!diff) + return this; + + (*ioDiff)++; + + AndType* substType = m_astBuilder->create(); + substType->left = substLeft; + substType->right = substRight; + return substType; +} + } // namespace Slang -- cgit v1.2.3