<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>Skimming it again, here's some brief commentary on your other suggestions:</div>
<div> </div>
<div>On Wed, Dec 30, 2015, at 02:50 PM, Howard Lovatt via swift-evolution wrote:<br></div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><ol start="1"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Generic protocol with type parameters inside `<>`, like classes and structs</span><br></li></ol></div>
</div>
</blockquote><div> </div>
<div>I believe this has already been proposed.</div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><ol start="2"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Allow covariant return types including for generic types</span><br></li></ol></div>
</div>
</blockquote><div> </div>
<div>I'm not sure what you mean by this. The return type of a function is already covariant. As for generics, I'm not sure how the compiler is supposed to know whether any other type U is a subtype of a generic type T. In theory, we could modify Swift to allow you to say something like<br></div>
<div> </div>
<div>func foo<T: AnyObject, U: T>(_: T.Type, _ x: U) -> T {<br></div>
<div> return x<br></div>
<div>}<br></div>
<div> </div>
<div>(right now this fails on the `U: T` because it doesn't know that T is a class type despite the previous bound of `T: AnyObject`)<br></div>
<div> </div>
<div>But I can't think of where this would actually be useful in practice to do (which may be why Swift doesn't bother to support it).<br></div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><ol start="3"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Treat Self as a shorthand for the type name; in particular as though there was an extra genetic type, `Type<Self: Type>` and everywhere `Self` appeared in the body the compiler substitutes `Type`</span><br></li></ol></div>
</div>
</blockquote><div> </div>
<div>I suspect this has been proposed before; I know I filed a radar for this a long time ago. Although just to be clear, what I'm thinking of is simply the ability to use the token `Self` anywhere inside a type definition as a convenient way to refer to the enclosing type, and not actually changing anything about generics or type parameters.</div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><ol start="4"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Allow `GenericTypeName.dynamicType` to return the metatype of a generic type</span><br></li></ol></div>
</div>
</blockquote><div> </div>
<div>You can already say `T.self.dynamicType` to get the metatype.</div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><ol start="5"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Treat typealias as introducing a generic type parameter that is not part of the type's type signature (or whatever it is renamed to)</span><br></li></ol></div>
</div>
</blockquote><div> </div>
<div>I have no idea what you mean by this. How can you have a type parameter that's not part of the type parameters list?</div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><ol start="6"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Allow implementations in protocols as well as in extensions to protocols (I think this is on the cards already)</span><br></li></ol></div>
</div>
</blockquote><div> </div>
<div>This sounds not-unreasonable. Has it been proposed before?</div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><ol start="7"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Allow default stored properties and default inits in protocol, see `Holder` example below</span><br></li></ol></div>
</div>
</blockquote><div> </div>
<div>Your example below implies the addition of struct inheritance, which isn't really something we can support. Inheritance implies a subtyping relationship, but you cannot have some struct Foo be a subtype of some other struct Bar if for no other reason than the fact that structs are value types and so you cannot possibly substitute a value of type Foo in any code that expects a Bar as it would be the wrong size. You could add implicit coercions that _slice_ the value (similar to C++), but that's a pretty nasty route to go down. Note that your example already violates this; you can't call `printout(holder)` because a Holder<Int> is not the same size as as Holder<Any>. Besides, you can already define that function pretty easily with generics as `func printout<T>(value: Holder<T>)`. I feel like all you're really trying to accomplish here is the removal of generics from functions (since this looks awfully similar to what you'd get with covariant mutable Arrays).<br></div>
<div> </div>
<div>I suspect that what you really want is just a way to define common behavior that's included in other structs, which is basically protocols except you want to add stored properties too. So in a sense what you really want is just a way to "embed" one struct in another (a stored property containing a struct is a form of embedding, but I'm talking here about embedding all its members directly without going through a stored property). This is not a true subtyping relationship (see previous paragraph) but accomplishes what you want.<br></div>
<div> </div>
<div>If you want to propose such a thing, I'd suggest maybe defining it like<br></div>
<div> </div>
<div>struct HolderInt: embeds DefaultHolder<Int> {<br></div>
<div> // ...<br></div>
<div>}<br></div>
<div> </div>
<div>to make it clear that this isn't a subtyping thing (you could make "embeds" into a member, but that becomes a little confusing then when you realize that the new struct acquires all of the embedded structs methods/properties).<br></div>
<div> </div>
<div>That said, a fair amount of thought would have to go into doing this and making sure it's compatible with any future changes that we want to make to the language (it's definitely worth a proposal all on its own if you really want to do it).<br></div>
<div> </div>
<div>Of course, in the end your original suggestion of having a protocol with stored properties still doesn't work, because it would be impossible to declare protocol conformance for a type in an extension (which is a pretty serious limitation). And I'm not really sure what benefit you have with this over the current approach of simply having to declare the stored property in the actual struct.<br></div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><ol start="8"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Disallow overload of a function with a generically typed argument with a function whose argument is derived from the generic type, must be an override.</span><br></li></ol></div>
</div>
</blockquote><div> </div>
<div>I'm not sure what you mean by this. Can you elaborate? When you say "derived from the generic type", it makes me think you're talking about something like<br></div>
<div> </div>
<div>class Foo {<br></div>
<div> func foo<T: SequenceType>(x: T)<br></div>
<div>}<br></div>
<div> </div>
<div>class Bar : Foo {<br></div>
<div> func foo<T: SequenceType>(x: T.Generator)<br></div>
<div>}<br></div>
<div> </div>
<div>But I don't understand why you'd want that second function to be marked as an override; it's clearly _not_ an override, as it doesn't have the same type! Note that all overridden functions can call super.func(), but if you required the "override" keyword here you clearly can't call super.foo() as the "overridden" function has a different type signature.<br></div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><div><ol start="2"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">`Equatable` and co would not be a special type, could have arrays of `Equatable`s</span><br></li></ol></div>
</div>
</div>
</blockquote><div> </div>
<div>It's not a special type already, it's just a protocol. And as far as I can tell, nothing that you've described would allow you to to have an array of type `[Equatable]`. I suspect you're thinking that protocol type parameters + typealiases somehow being implicit type parameters would do this, except the type `[Equatable]` still doesn't declare the type. Or with the typealias thing did you actually intend to have `Equatable` look something like `Equatable<Self=T>`, thus allowing you to say `[Equatable<Self=Int>]`? But that doesn't actually work, because if you know that Self is an Int, then you'd just say `[Int]` instead.<br></div>
<div> </div>
<div>An argument can be made for allowing one to specify typealiases on existential protocol values, e.g. `GeneratorType<Element=Int>` (although that would get pretty unwieldy when you try to figure out how to specify a SequenceType or a CollectionType), but there's no sense in attempting to do that for Self, because if you set Self=T then you should just use a T directly instead of an existential protocol value.<br></div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><div><ol start="3"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">No need for `AnyXXX` types, the protocol does this directly</span><br></li></ol></div>
</div>
</div>
</blockquote><div> </div>
<div>No it doesn't. Barring the above-mentioned issues with specifying typealiases on existential protocol values, types like AnySequence also erase a lot of the specifics of the typealias. Even with your suggested changes, there'd be no way to say "SequenceType<Element=Int>" because that leaves the Generator and SubSequence types undefined, which means you can't actually do much at all with the existential protocol value. But AnySequence only has a parameter for the element type, the details of the generator and subsequence are erased.<br></div>
<div> </div>
<blockquote type="cite"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;"><div><ol start="4"><li><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">No need for `CollectionType` and `Array`, `Array` would become a `protocol` and a `struct`</span><br></li></ol></div>
</div>
</div>
</blockquote><div> </div>
<div>What? That doesn't make any sense. Even with your struct inheritance idea, Array can't possibly be the "base" for all collections. If you want a collection with the stored properties and behavior of Array, you just use an Array! The whole point of using other collections is because you want different behavior.<br></div>
<div> </div>
<div>-Kevin Ballard</div>
</body>
</html>