> On Jan 27, 2017, at 1:43 PM, Anton Zhilin via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Current alternative to default generic arguments is typealias, like
> basic_string and string in C++:
>
> struct BasicBigInt<T> { ... }
> typealias BigInt = BasicBigInt<Int64>
> It’s not that ugly. It keeps type inference rules simpler, easier to
> understand and more explicit.
> As someone noted, current type inference for generic initializers works
> satisfactory in 99% cases. Is it really worth it to try to cover 99.9% at the
> cost of complexity of type inference rules?
>
> On the other hand, in the wild, there may exist types with 3 or even more
> generic parameters that have sensible default values. [Research needed]
> For such complex cases, I think, it makes sense to add default generic
> parameters only together with generic parameter labels.
> Also, in such cases, functions on types could often help. And that story is
> even out of scope of Swift 4 Phase 2.
>
If we could overload the type's name, I think that’d solve my use-case pretty
much completely:
protocol Endian {}
class BigEndian : Endian {}
class LittleEndian : Endian {}
class NativeEndian : Endian {}
struct BigInt<Chunk _: Integer, Endian _: Endian> {...} //Made-up syntax for
indicating the generic parameters’ labels should be the same both internally
and externally
typealias BigInt<T> = BigInt<Chunk: T, Endian: NativeEndian> where T: Integer
typealias BigInt = BigInt<Int>
- Dave Sweeris_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
