In fact why not just use the generics syntax with protocols ? Anybody
implementing a "Generic" Protocol has to specify the types.
protocol Collection<Key, Value >
{
func get(key: Key) -> Value?
}
class StringCollection: Collection<Key: String, Value: String>
{
}
class GenericCollection<Type>: Collection<Key: Type, Value: Type>
{
}
···
On Wed, Dec 23, 2015 at 11:18 AM, James Campbell <james@supmenow.com> wrote:
Maybe you could use the phrase "placeholder" type. If you think about it.
typealias is a way of "aliasing" the type. i.e "Type B is just another name
for Type C"
Associated type I always found a bit confusing, associated with what ? A
placeholder type I feel explains it more plainly. Associated types are
nothing but placeholders.
So this is my example:
protocol Collection
{
typeplaceholder T
func first() -> T?
}
class IntCollection: Collection
{
typeplaceholder T = Int
}
potentially you could provide some sort of syntax for setting it in the
subclass part of the code.
protocol Collection
{
typeplaceholder T
func first() -> T?
}
class IntCollection: Collection<T:Int> //The T type placeholder is now an
Int
{
}
class GenericCollection<F>: Collection<T:F> //The T type placeholder is
now what ever the generic F is set to.
{
}
On Wed, Dec 23, 2015 at 11:00 AM, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote:
> "Associated type" is the name of this feature
The name of the concept is highly inexpressive, and I guess it's far
easier to change the docs than to change the language…
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
These don’t really speak to me, just because they aren’t the terminology that people use to refer to these. “standin” and “placeholder” are also pretty vacuous.
-Chris
···
On Dec 23, 2015, at 9:59 AM, Erica Sadun <erica@ericasadun.com> wrote:
And what are your feelings about: typestandin, typeplaceholder, or adoptedtype? How would you describe the functionality of these members if you weren't looking for a keyword?
On Dec 23, 2015, at 12:41 PM, Chris Lattner <clattner@apple.com> wrote:
On Dec 23, 2015, at 10:25 AM, Dave Abrahams <dabrahams@apple.com> wrote:
Of the three, I prefer “associatedtype”.
We already have precedent for concatenated names in a very related sort of decl (typealias), and this will be a real keyword.
Here are how I see the pros and cons I see of these options:
type:
- Overly short, particularly given the infrequency of these decls, the common case of “type Element” will be weird floating around given its lack of weight.
I don’t understand how that’s different from, e.g.
init()
or
var x: Int
which will both show up in protocol declarations. Could you explain?
It follows from the same logic that makes “typealias” have a long name, instead of being named “type” or “typ” ;-)
typealiases and associated types are both *much* less frequently used than variables or functions. var and func make sense to keep very short because of their frequency, and because every swift programmer is expected to memorize what they do. “init” is less defensible on these terms, because it is more rare, but is clear, and shares commonality with some ObjC heritage.
If you compare typealiases and associated types, these are *much* more infrequently used than any of these three, they are effectively a advanced generics feature. Because they are less frequent, people shouldn’t be expected to memorize what they are, and googlability does matter.
- Overly unclear. This is a very specific kind of type, not a generic type you can use in other contexts.
Could you explain what you mean by this? If anything I see this exactly opposite. It’s a requirement for a type, *any* kind of type, be it struct, class, enum, non-nominal type such as tuple or function, whatever—so long as it satisfies the constraints placed it. That’s about as generic as one can get.
This is a declaration of a requirement of a type. This is not declaring a type. This keyword cannot be used in any other place in the grammar. People would reasonably expect to use a keyword like “type” elsewhere. This keyword is completely different than init/var/func in that sense.
- Unfortunate keyword. Among other things it would make writing compilers in swift a pain :-), but again, people would want to use this in other places.
I don’t see how this would actually cause a problem if it was contextual.
Besides the parser ambiguities? We could probably force it to work, but it would be unnecessary complexity. All statements and decls should start with a keyword. This enables attributes and declmodifiers to “just work”, you lose that if you play games with context sensitive keywords.
There’s no reason one couldn’t name a property “type” if one wanted to. These two things will appear in *very* different contexts, so I don’t think humans would have a hard time de-contextualizing.
I agree, that’s exactly why I don’t think it should be called “type”. They are very different things.
In fact why not just use the generics syntax with protocols ? Anybody implementing a "Generic" Protocol has to specify the types.
That's a simple solution, but inconvenient:
One use case for placeholders (I don't use the official name here to propagate an alternative ;-) is when you have a types that depend on a parameter.
I'm to lazy to look up a real example, but Array<Int> is naturally associated with an enumerator for Int — and it is no fun to be forced to include such relationships all over the place.
> In fact why not just use the generics syntax with protocols ? Anybody
implementing a "Generic" Protocol has to specify the types.
That's a simple solution, but inconvenient:
One use case for placeholders (I don't use the official name here to
propagate an alternative ;-) is when you have a types that depend on a
parameter.
I'm to lazy to look up a real example, but Array<Int> is naturally
associated with an enumerator for Int — and it is no fun to be forced to
include such relationships all over the place.
So in my example with placeholders.
class GenericCollection<Type>: Collection<Key: Type, Value: Type>
{
}
Has already specified the type of the placeholder :) so subclasses don't
need to specify it. In this example the Key and Value type placeholders are
bound to whatever the Type is.
So in these examples
let items: GenericCollection<Int> = GenericCollection()
or
let items: [Int] =
the Key and Value type placeholders would be Ints :) since the generic type
is an Int.
The thing is associated type means nothing to me, it's too technical. Placeholder type I think would be better even if it's only what we called it in the documentation
···
Sent from my iPhone
On 23 Dec 2015, at 20:35, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 23, 2015, at 9:59 AM, Erica Sadun <erica@ericasadun.com> wrote:
And what are your feelings about: typestandin, typeplaceholder, or adoptedtype? How would you describe the functionality of these members if you weren't looking for a keyword?
These don’t really speak to me, just because they aren’t the terminology that people use to refer to these. “standin” and “placeholder” are also pretty vacuous.
James or Erica (or someone else), can you explain what makes these types "placeholders"? I don't think of the other requirements in a protocol as "placeholder properties" or "placeholder methods".
My explanation of these things is "When a particular type X conforms to a protocol, you can ask about the types that X uses to implement the requirements of the protocol". I guess we could call them "related types" instead of "associated types", but that doesn't seem significantly different.
Jordan
···
On Dec 23, 2015, at 12:42, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:
The thing is associated type means nothing to me, it's too technical. Placeholder type I think would be better even if it's only what we called it in the documentation
The thing is associated type means nothing to me, it's too technical. Placeholder type I think would be better even if it's only what we called it in the documentation
Programming languages are technical and it has a very clear meaning in Swift.
···
Sent from my iPhone
On Dec 23, 2015, at 2:42 PM, James Campbell via swift-evolution <swift-evolution@swift.org> wrote:
Sent from my iPhone
On 23 Dec 2015, at 20:35, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 23, 2015, at 9:59 AM, Erica Sadun <erica@ericasadun.com> wrote:
And what are your feelings about: typestandin, typeplaceholder, or adoptedtype? How would you describe the functionality of these members if you weren't looking for a keyword?
These don’t really speak to me, just because they aren’t the terminology that people use to refer to these. “standin” and “placeholder” are also pretty vacuous.
Item is a placeholder for a concrete type, at this moment this is a concept
"A collection should return an item of a type" but we don't know what that
type is as its a plaeholder for a type.
therefore in:
class IntCollection: Collection
{
placeholder Item = Int
}
We are saying that the placeholder should now become a concrete type. In my
eyes associated types are nothing more than generics for protocols which in
turn could be argued is some kind of placeholder.
Associated type means nothing to me, associated to what ? A type could be
associated to many things like a variable, or a generic or whatever. A
placeholder to mean does what it says on the tin. If we moved to protocols
using a syntax closer to generics for classes then I think it would be
simpilar to grasp for beginners .
···
On Wed, Dec 23, 2015 at 9:35 PM, Jordan Rose <jordan_rose@apple.com> wrote:
James or Erica (or someone else), can you explain what makes these types
"placeholders"? I don't think of the other requirements in a protocol as
"placeholder properties" or "placeholder methods".
My explanation of these things is "When a particular type X conforms to a
protocol, you can ask about the types that X uses to implement the
requirements of the protocol". I guess we could call them "related types"
instead of "associated types", but that doesn't seem significantly
different.
Jordan
> On Dec 23, 2015, at 12:42, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote:
>
> The thing is associated type means nothing to me, it's too technical.
Placeholder type I think would be better even if it's only what we called
it in the documentation
>
> Sent from my iPhone
If we made class, structs, protocols and functions use the same generics
syntax then I think it would make it more consistent rather than arguing
about which keyword to use. I am for-ever being tripped up by lack of
generics in the language.
class IntBag : Collection<Int> //We bind protocol "associated type" using
generic syntax when subclassing. In this case we are saying Item should be
type Int
{
}
class Array<Item>: Collection<Item> //We bind protocol "associated type"
using generic syntax when subclassing. In this case we are saying Item
should be the same type as the generic type for Array
{
}
IntBag()
Array<Int>()
···
On Wed, Dec 23, 2015 at 10:58 PM, James Campbell <james@supmenow.com> wrote:
They are placeholders because in the protocol:
prtocotol Collection
{
placeholder Item
func first() -> Item?
{
}
}
Item is a placeholder for a concrete type, at this moment this is a
concept "A collection should return an item of a type" but we don't know
what that type is as its a plaeholder for a type.
therefore in:
class IntCollection: Collection
{
placeholder Item = Int
}
We are saying that the placeholder should now become a concrete type. In
my eyes associated types are nothing more than generics for protocols which
in turn could be argued is some kind of placeholder.
Associated type means nothing to me, associated to what ? A type could be
associated to many things like a variable, or a generic or whatever. A
placeholder to mean does what it says on the tin. If we moved to protocols
using a syntax closer to generics for classes then I think it would be
simpilar to grasp for beginners .
On Wed, Dec 23, 2015 at 9:35 PM, Jordan Rose <jordan_rose@apple.com> > wrote:
James or Erica (or someone else), can you explain what makes these types
"placeholders"? I don't think of the other requirements in a protocol as
"placeholder properties" or "placeholder methods".
My explanation of these things is "When a particular type X conforms to a
protocol, you can ask about the types that X uses to implement the
requirements of the protocol". I guess we could call them "related types"
instead of "associated types", but that doesn't seem significantly
different.
Jordan
> On Dec 23, 2015, at 12:42, James Campbell via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> The thing is associated type means nothing to me, it's too technical.
Placeholder type I think would be better even if it's only what we called
it in the documentation
>
> Sent from my iPhone
There's a problem here because associated types aren't the same as generics.
I've been looking this up a lot recently because I've been trying to create
a delegate protocol for a generic type. The GenericType<X> requires a
GenericTypeDelegate<X> and Swift 2 protocols just don't support those yet;
the best workaround of the moment seems to be a wrapper type which wraps
the delegate's functions in closures.
This is a different concept to associated types. I've seen a couple of
examples around; the one I'm remembering at the moment involves a protocol
for Animals requiring them to have an associated Food type. A Cow could
thus be defined as a type implementing the Animal protocol, with an
associated type of Grass; this would be very different to an Animal being a
generic type, and a Cow being (perhaps typealiased as) an Animal<Grass>.
With the associated type, the Cow is known to always eat Grass; with the
generic type, every function is written to handle all foodstuffs.
So, no, the two different syntaxes are required - but protocols with
generic parameters (is that the right term for e.g. Grass in
Animal<Grass>?) would be a good addition to the language.
···
On Wed, Dec 23, 2015 at 11:06 PM, James Campbell via swift-evolution < swift-evolution@swift.org> wrote:
If we made class, structs, protocols and functions use the same generics
syntax then I think it would make it more consistent rather than arguing
about which keyword to use. I am for-ever being tripped up by lack of
generics in the language.
class IntBag : Collection<Int> //We bind protocol "associated type" using
generic syntax when subclassing. In this case we are saying Item should be
type Int
{
}
class Array<Item>: Collection<Item> //We bind protocol "associated type"
using generic syntax when subclassing. In this case we are saying Item
should be the same type as the generic type for Array
{
}
IntBag()
Array<Int>()
On Wed, Dec 23, 2015 at 10:58 PM, James Campbell <james@supmenow.com> > wrote:
They are placeholders because in the protocol:
prtocotol Collection
{
placeholder Item
func first() -> Item?
{
}
}
Item is a placeholder for a concrete type, at this moment this is a
concept "A collection should return an item of a type" but we don't know
what that type is as its a plaeholder for a type.
therefore in:
class IntCollection: Collection
{
placeholder Item = Int
}
We are saying that the placeholder should now become a concrete type. In
my eyes associated types are nothing more than generics for protocols which
in turn could be argued is some kind of placeholder.
Associated type means nothing to me, associated to what ? A type could be
associated to many things like a variable, or a generic or whatever. A
placeholder to mean does what it says on the tin. If we moved to protocols
using a syntax closer to generics for classes then I think it would be
simpilar to grasp for beginners .
On Wed, Dec 23, 2015 at 9:35 PM, Jordan Rose <jordan_rose@apple.com> >> wrote:
James or Erica (or someone else), can you explain what makes these types
"placeholders"? I don't think of the other requirements in a protocol as
"placeholder properties" or "placeholder methods".
My explanation of these things is "When a particular type X conforms to
a protocol, you can ask about the types that X uses to implement the
requirements of the protocol". I guess we could call them "related types"
instead of "associated types", but that doesn't seem significantly
different.
Jordan
> On Dec 23, 2015, at 12:42, James Campbell via swift-evolution < >>> swift-evolution@swift.org> wrote:
>
> The thing is associated type means nothing to me, it's too technical.
Placeholder type I think would be better even if it's only what we called
it in the documentation
>
> Sent from my iPhone
What about templatetype ? This could also work if we started referring
generics as Templates :) and extended them to protocols and functions.
···
On Sat, Dec 26, 2015 at 3:15 PM, Ross O'Brien <narrativium+swift@gmail.com> wrote:
There's a problem here because associated types aren't the same as
generics.
I've been looking this up a lot recently because I've been trying to
create a delegate protocol for a generic type. The GenericType<X> requires
a GenericTypeDelegate<X> and Swift 2 protocols just don't support those
yet; the best workaround of the moment seems to be a wrapper type which
wraps the delegate's functions in closures.
This is a different concept to associated types. I've seen a couple of
examples around; the one I'm remembering at the moment involves a protocol
for Animals requiring them to have an associated Food type. A Cow could
thus be defined as a type implementing the Animal protocol, with an
associated type of Grass; this would be very different to an Animal being a
generic type, and a Cow being (perhaps typealiased as) an Animal<Grass>.
With the associated type, the Cow is known to always eat Grass; with the
generic type, every function is written to handle all foodstuffs.
So, no, the two different syntaxes are required - but protocols with
generic parameters (is that the right term for e.g. Grass in
Animal<Grass>?) would be a good addition to the language.
On Wed, Dec 23, 2015 at 11:06 PM, James Campbell via swift-evolution < > swift-evolution@swift.org> wrote:
If we made class, structs, protocols and functions use the same generics
syntax then I think it would make it more consistent rather than arguing
about which keyword to use. I am for-ever being tripped up by lack of
generics in the language.
class IntBag : Collection<Int> //We bind protocol "associated type" using
generic syntax when subclassing. In this case we are saying Item should be
type Int
{
}
class Array<Item>: Collection<Item> //We bind protocol "associated type"
using generic syntax when subclassing. In this case we are saying Item
should be the same type as the generic type for Array
{
}
IntBag()
Array<Int>()
On Wed, Dec 23, 2015 at 10:58 PM, James Campbell <james@supmenow.com> >> wrote:
They are placeholders because in the protocol:
prtocotol Collection
{
placeholder Item
func first() -> Item?
{
}
}
Item is a placeholder for a concrete type, at this moment this is a
concept "A collection should return an item of a type" but we don't know
what that type is as its a plaeholder for a type.
therefore in:
class IntCollection: Collection
{
placeholder Item = Int
}
We are saying that the placeholder should now become a concrete type. In
my eyes associated types are nothing more than generics for protocols which
in turn could be argued is some kind of placeholder.
Associated type means nothing to me, associated to what ? A type could
be associated to many things like a variable, or a generic or whatever. A
placeholder to mean does what it says on the tin. If we moved to protocols
using a syntax closer to generics for classes then I think it would be
simpilar to grasp for beginners .
On Wed, Dec 23, 2015 at 9:35 PM, Jordan Rose <jordan_rose@apple.com> >>> wrote:
James or Erica (or someone else), can you explain what makes these
types "placeholders"? I don't think of the other requirements in a protocol
as "placeholder properties" or "placeholder methods".
My explanation of these things is "When a particular type X conforms to
a protocol, you can ask about the types that X uses to implement the
requirements of the protocol". I guess we could call them "related types"
instead of "associated types", but that doesn't seem significantly
different.
Jordan
> On Dec 23, 2015, at 12:42, James Campbell via swift-evolution < >>>> swift-evolution@swift.org> wrote:
>
> The thing is associated type means nothing to me, it's too technical.
Placeholder type I think would be better even if it's only what we called
it in the documentation
>
> Sent from my iPhone