2 people (out of 100) chose “other” and specified “type”. Sadly it wasn’t presented as an option, sorry :(
I'm not a big fan of simple surveys in general, but isn't there a better platform than surveymonkey?
Sure, it has nice graphs, but doodle once had the option to add possible answers — and I can't even see a way to read the full results, so could you publish the numbers for the "other"-votes?
Best regards,
Tino
As SE-0011 states, the concept of typealias is overloaded.
In one case, it's really just typedef.
In the other it's a stand-in for a deferred type that is specified by conforming classes.
While you could argue that the other typealias be redefined to typedef, it's pretty clear that in use, what's being described in the second case is an associated type. The word associated means related to or connected to, and type well it's a type. It basically says "this is a placeholder type that establishes a specific role in this protocol". I think associatedtype is a pretty good word to describe what a second-style typealias does: a conforming construct binds an associated type with an actual type instance.The phrase "associated type" is used throughout the Swift Programming Language book, for example: "When defining a protocol, it is sometimes useful to declare one or more associated types as part of the protocol’s definition. An associated type gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that associated type is not specified until the protocol is adopted."
Some argue for raw type as the replacement:
Dave Abrahams writes, "I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars."
Joe Groff writes, "Yeah, if we could make 'type' work I'd prefer that too. None of our other protocol requirement declarations specifically call out the fact that they're protocol requirements, so it feels a bit weird to use a name like 'associatedtype' or 'requiredsomething' that belabors the relationship between the protocol and the requirement."
Type members are unlike the other kinds of required protocol members, like a property, method, initializer, or subscript requirement. They aren't implemented by a conforming construct or extension.I don’t see how this:
protocol P { type/*alias*/ A}
struct X : P { struct A {} }is fundamentally any different from:
protocol P { func f()}
struct X : P { func f() {}}What am I missing?
You're not using func f() elsewhere as a return type, a parameter type, in generic constraints, etc. Other member requirements are Jeff Goldblum and typealiases are Chuck Norris.
They provide a fundamental grammar for other tasks.
Quick reference I ended up generating so I could keep all of my possible expressiveness at hand. It may or may not add to your thoughts about this:
https://gist.githubusercontent.com/erica/c50f8f213db1be3e6390/raw/2888276fcad56d68016f864e6e0e9f689f597aac/0%2520Conformances%2520and%2520Associated%2520Types
They act as stand-in or placeholder: assigned not implemented. They can even be assigned as a default in the protocol definition, for example: typealias Generator : GeneratorType = IndexingGenerator<Self> in CollectionType.
The way defaults are specified is a non-uniformity that we want to fix. There’s no reason we couldn’t be providing default implementations of required protocol methods in the protocol body either.
Cool. Power to the protocol!
Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, I don't really see any reason to introduce a keyword other than associatedtype for this proposal.
And bringing a point from a later email: easier to google.
-- E
On Dec 22, 2015, at 6:25 PM, Dave Abrahams <dabrahams@apple.com> wrote:
On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-- E
On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
When you're actually implementing a generic function, the generic parameter is [snip]
Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using the idea of a parameter would solidify the conceptual relationship between protocols-with-associated-types and generics.
protocol P {
parameter T
}Guillaume Lessard
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-Dave
Well, in the context of a generic function or generic type, we have “type parameter” and “generic parameter clauses”. Is a protocol's associated type truly so different that it requires a different name? Note that many people out there are calling a protocol-with-associated-type a “generic protocol”.
Cheers,
Guillaume Lessard
On 22 déc. 2015, at 19:01, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution <swift-evolution@swift.org> wrote:
“parameter” is a good thought. On it’s own it seems like it’s missing something though. But it gives me other ideas: “typeparam”, “type param", “typeparameter”, or “type parameter”.
It’s not a parameter, though, because it does not vary the way a parameter does: a given type X cannot conform to a protocol with two different bindings for a given associated type.
Yes, true, it’s not quite a parameter because it can’t vary. But in the sense that it’s a slot that you have to provide a value for, you might call it a parameter. Having the syntax be “type parameter” gives a further hint that there’s more to it than a regular parameter.
But having said that, everything in a protocol is a slot that you have to provide a value for, so that makes me think that just plain “type” may be better after all, which is the way I’m now leaning.
“associated type” has some good points too, e.g., that is what the feature is called. It just seems a little redundant, and verbose. We already know it’s associated because it’s inside the braces. It doesn’t say anything about the nature of the association, which is: “this is something you have to fill in”. I don’t see any problem in referring to the feature as associated types, but then having the syntax be just plain “type”.
Matt
On Dec 22, 2015, at 18:01, Douglas Gregor <dgregor@apple.com> wrote:
On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution <swift-evolution@swift.org> wrote:
“parameter” is a good thought. On it’s own it seems like it’s missing something though. But it gives me other ideas: “typeparam”, “type param", “typeparameter”, or “type parameter”.
It’s not a parameter, though, because it does not vary the way a parameter does: a given type X cannot conform to a protocol with two different bindings for a given associated type.
- Doug
I would much prefer one of the longer terms such as 'associatedtype' to
'type'. The simple reason why: I've been using a lot of generics for a
while and I still find it tricky. I want a term I can type into a search
engine and expect results for, and 'type's too common for that.
On Tue, Dec 22, 2015 at 8:42 PM, Matt Whiteside via swift-evolution < swift-evolution@swift.org> wrote:
The fact that “associated type” is used throughout the documentation is
worth making note of, but it could also be that some other replacement
would make the concept more clear than it currently is in the documentation.Matt
On Dec 22, 2015, at 09:30, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
The phrase "associated type" is used throughout the Swift Programming
Language book, for example: "When defining a protocol, it is sometimes
useful to declare one or more *associated types* as part of the
protocol’s definition. An *associated type* gives a placeholder name (or
alias) to a type that is used as part of the protocol. The actual type to
use for that *associated type* is not specified until the protocol is
adopted."_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I don’t see how this:
protocol P {
type/*alias*/ A
}struct X : P {
struct A {}
}is fundamentally any different from:
protocol P {
func f()
}struct X : P {
func f() {}
}What am I missing?
I'd say it's the fact that adding an associated type turns a protocol into a frankenprotocol, and we don't want that to be cast upon innocent souls without a proper curse word (like "associatedtype").
Also, maybe some day we'll have normal type requirements — something that has to be defined in a protocol, but does not turn it into a frankenprotocol than nobody can use anymore. That would be an appropriate use of the normal-looking keywords.
A.
As SE-0011 states, the concept of typealias is overloaded.
In one case, it's really just typedef.
In the other it's a stand-in for a deferred type that is specified by conforming classes.
While you could argue that the other typealias be redefined to typedef, it's pretty clear that in use, what's being described in the second case is an associated type. The word associated means related to or connected to, and type well it's a type. It basically says "this is a placeholder type that establishes a specific role in this protocol". I think associatedtype is a pretty good word to describe what a second-style typealias does: a conforming construct binds an associated type with an actual type instance.The phrase "associated type" is used throughout the Swift Programming Language book, for example: "When defining a protocol, it is sometimes useful to declare one or more associated types as part of the protocol’s definition. An associated type gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that associated type is not specified until the protocol is adopted."
Some argue for raw type as the replacement:
Dave Abrahams writes, "I’m actually coming around to wanting it to be just “type” as a contextual keyword, if we can make that work. The point is that these types aren’t “associated” in any way that distinguishes them from other requirements on nested declarations, i.e. funcs and vars."
Joe Groff writes, "Yeah, if we could make 'type' work I'd prefer that too. None of our other protocol requirement declarations specifically call out the fact that they're protocol requirements, so it feels a bit weird to use a name like 'associatedtype' or 'requiredsomething' that belabors the relationship between the protocol and the requirement."
Type members are unlike the other kinds of required protocol members, like a property, method, initializer, or subscript requirement. They aren't implemented by a conforming construct or extension.I don’t see how this:
protocol P { type/*alias*/ A}
struct X : P { struct A {} }is fundamentally any different from:
protocol P { func f()}
struct X : P { func f() {}}What am I missing?
You're not using func f() elsewhere as a return type, a parameter type, in generic constraints, etc. Other member requirements are Jeff Goldblum and typealiases are Chuck Norris.
I’m sorry, I’m missing your metaphor.
They provide a fundamental grammar for other tasks.
Yes, other requirements may depend on associated types. They’re still requirements.
Quick reference I ended up generating so I could keep all of my possible expressiveness at hand. It may or may not add to your thoughts about this:
https://gist.githubusercontent.com/erica/c50f8f213db1be3e6390/raw/2888276fcad56d68016f864e6e0e9f689f597aac/0%2520Conformances%2520and%2520Associated%2520Types <https://gist.githubusercontent.com/erica/c50f8f213db1be3e6390/raw/2888276fcad56d68016f864e6e0e9f689f597aac/0%20Conformances%20and%20Associated%20Types>
Sorry, I’m not sure what insight that list is supposed to spark. Be assured, I have generated many such tables, graphs, etc. for myself in the past :-)
They act as stand-in or placeholder: assigned not implemented. They can even be assigned as a default in the protocol definition, for example: typealias Generator : GeneratorType = IndexingGenerator<Self> in CollectionType.
The way defaults are specified is a non-uniformity that we want to fix. There’s no reason we couldn’t be providing default implementations of required protocol methods in the protocol body either.
Cool. Power to the protocol!
Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, I don't really see any reason to introduce a keyword other than associatedtype for this proposal.
And bringing a point from a later email: easier to google.
Undeniably.
-- E
-- E
When you're actually implementing a generic function, the generic parameter is [snip]
Here's a word with meaning: parameter. Everything else I've seen sounds vague or approximate. Using the idea of a parameter would solidify the conceptual relationship between protocols-with-associated-types and generics.
protocol P {
parameter T
}Guillaume Lessard
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-Dave
-Dave
On Dec 22, 2015, at 5:51 PM, Erica Sadun <erica@ericasadun.com> wrote:
On Dec 22, 2015, at 6:25 PM, Dave Abrahams <dabrahams@apple.com <mailto:dabrahams@apple.com>> wrote:
On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I don’t see any problem in referring to the feature as associated types, but then having the syntax be just plain “type”.
I think it's been said before, but the problem with using a `type` keyword is that if you type "swift type" into Google (or any other search feature you might use for documentation), you're probably not going to get information about this feature specifically. "swift associated" or "swift associatedtype" are more likely to give you what you want.
--
Brent Royal-Gordon
Architechies
I did see that point made earlier in the thread, but I’m not convinced that design for googleability is the right ordering of priorities. I think people will probably figure out that they need to search for “swift protocol type” or whatever the final choice ends up being.
On Dec 22, 2015, at 20:54, Brent Royal-Gordon <brent@architechies.com> wrote:
I don’t see any problem in referring to the feature as associated types, but then having the syntax be just plain “type”.
I think it's been said before, but the problem with using a `type` keyword is that if you type "swift type" into Google (or any other search feature you might use for documentation), you're probably not going to get information about this feature specifically. "swift associated" or "swift associatedtype" are more likely to give you what you want.
--
Brent Royal-Gordon
Architechies
I don’t understand this argument about googleability of “type” being a problem. All of the errors and documentation talk about “associated type” and having the word “type” literally visually associated with the word “protocol” right there in the code I’m looking at makes perfect sense to me.
Since all of the error messages say “associated type”, I’d be googling a phrase that includes the error message somehow such as “swift associated type” or “swift protocol type” or something else and I’d almost certainly land on the right documentation no matter what the keyword is.
The keyword doesn’t matter much as long as the error messages can be searched for.
All that said, though, the single most confusing aspect of associated types, for me, was that “typealias” allowed me to specify a default type - and because of that *one* thing, I initially thought it behaved exactly like “typealias” when outside of a protocol and did not understand the relationship for quite awhile. Frankly, I think this whole mess *could* be solved simply by not allowing “default” types when using the typealias keyword in a protocol. In that case, attempting to do so would generate an error, and then searching for that error would lead to an explanation of what “typealias” really means when inside of a protocol and a whole ton of confusion could be avoided from the start - without changing any keywords.
l8r
Sean
On Dec 22, 2015, at 10:54 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
I don’t see any problem in referring to the feature as associated types, but then having the syntax be just plain “type”.
I think it's been said before, but the problem with using a `type` keyword is that if you type "swift type" into Google (or any other search feature you might use for documentation), you're probably not going to get information about this feature specifically. "swift associated" or "swift associatedtype" are more likely to give you what you want.
--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I did see that point made earlier in the thread, but I’m not convinced that design for googleability is the right ordering of priorities.
+1
Choosing cryptic names because it's easier to find information about them is bad. With this argument, you can not only fight against removal of the NextStep prefix (Data, Number, Date… try googling that), but also demand that the language should be spelled "Sweeft", and that framework functions should loose their meaningful names and get called by a UUID instead.
I did see that point made earlier in the thread, but I’m not convinced that design for googleability is the right ordering of priorities.
+1
Choosing cryptic names because it's easier to find information about them is bad. With this argument, you can not only fight against removal of the NextStep prefix (Data, Number, Date… try googling that), but also demand that the language should be spelled "Sweeft", and that framework functions should loose their meaningful names and get called by a UUID instead.
I don't think the `associated` keyword is cryptic; I think it's *specific*. "Associated type" is the name of this feature. We tried bikeshedding it upthread, and didn't come up with anything better. If you're going to use a keyword related to the name "associated type", that leaves you with `associated`, `type`, or `associatedtype`. Of these three, `type` is extremely vague (and also something we've resisted taking as a keyword—see the discussion about `SomeType.self` last week), `associatedtype` is an overlong, awkward concatenation of two words, and `associated` has neither of those failings. That's why I favor it.
--
Brent Royal-Gordon
Architechies
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.
- Overly unclear. This is a very specific kind of type, not a generic type you can use in other contexts.
- 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.
associated:
- Vacuous: doesn’t mean anything on its own: “associated Element”.
- Somewhat unfortunate as a keyword, but much less so than type.
associatedtype:
- Clean in context: “associatedtype Element”
- Obvious you wouldn’t want to use it in another context.
- Googlable, unambiguous
-Chris
On Dec 23, 2015, at 2:08 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
I did see that point made earlier in the thread, but I’m not convinced that design for googleability is the right ordering of priorities.
+1
Choosing cryptic names because it's easier to find information about them is bad. With this argument, you can not only fight against removal of the NextStep prefix (Data, Number, Date… try googling that), but also demand that the language should be spelled "Sweeft", and that framework functions should loose their meaningful names and get called by a UUID instead.I don't think the `associated` keyword is cryptic; I think it's *specific*. "Associated type" is the name of this feature. We tried bikeshedding it upthread, and didn't come up with anything better. If you're going to use a keyword related to the name "associated type", that leaves you with `associated`, `type`, or `associatedtype`.
+1 for associated
On Wed, Dec 23, 2015 at 10:08 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:
>> I did see that point made earlier in the thread, but I’m not convinced
that design for googleability is the right ordering of priorities.
> +1
> Choosing cryptic names because it's easier to find information about
them is bad. With this argument, you can not only fight against removal of
the NextStep prefix (Data, Number, Date… try googling that), but also
demand that the language should be spelled "Sweeft", and that framework
functions should loose their meaningful names and get called by a UUID
instead.I don't think the `associated` keyword is cryptic; I think it's
*specific*. "Associated type" is the name of this feature. We tried
bikeshedding it upthread, and didn't come up with anything better. If
you're going to use a keyword related to the name "associated type", that
leaves you with `associated`, `type`, or `associatedtype`. Of these three,
`type` is extremely vague (and also something we've resisted taking as a
keyword—see the discussion about `SomeType.self` last week),
`associatedtype` is an overlong, awkward concatenation of two words, and
`associated` has neither of those failings. That's why I favor it.--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Wizard
james@supmenow.com
+44 7523 279 698
I did see that point made earlier in the thread, but I’m not convinced that design for googleability is the right ordering of priorities.
+1
Choosing cryptic names because it's easier to find information about them is bad. With this argument, you can not only fight against removal of the NextStep prefix (Data, Number, Date… try googling that), but also demand that the language should be spelled "Sweeft", and that framework functions should loose their meaningful names and get called by a UUID instead.I don't think the `associated` keyword is cryptic; I think it's *specific*. "Associated type" is the name of this feature. We tried bikeshedding it upthread, and didn't come up with anything better. If you're going to use a keyword related to the name "associated type", that leaves you with `associated`, `type`, or `associatedtype`.
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?
- 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.
- 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. 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.
associated:
- Vacuous: doesn’t mean anything on its own: “associated Element”.
Heh, now that I look at that, provided we can be consistent about only UpperCamelCasing type names it actually might be sufficiently communicative. Just a thought.
- Somewhat unfortunate as a keyword, but much less so than type.
associatedtype:
- Clean in context: “associatedtype Element”
- Obvious you wouldn’t want to use it in another context.
- Googlable, unambiguous-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-Dave
On Dec 23, 2015, at 8:34 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 23, 2015, at 2:08 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
Add to the “associatedtype” advantages that, unlike the other two, it passes the “unfortunate keyword” test with flying colors. I don’t often want to name a variable “associatedtype”.
Cheers, P
On Dec 23, 2015, at 10:34 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
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.
- Overly unclear. This is a very specific kind of type, not a generic type you can use in other contexts.
- 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.associated:
- Vacuous: doesn’t mean anything on its own: “associated Element”.
- Somewhat unfortunate as a keyword, but much less so than type.associatedtype:
- Clean in context: “associatedtype Element”
- Obvious you wouldn’t want to use it in another context.
- Googlable, unambiguous
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?
-- E
On Dec 23, 2015, at 9:34 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 23, 2015, at 2:08 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
I did see that point made earlier in the thread, but I’m not convinced that design for googleability is the right ordering of priorities.
+1
Choosing cryptic names because it's easier to find information about them is bad. With this argument, you can not only fight against removal of the NextStep prefix (Data, Number, Date… try googling that), but also demand that the language should be spelled "Sweeft", and that framework functions should loose their meaningful names and get called by a UUID instead.I don't think the `associated` keyword is cryptic; I think it's *specific*. "Associated type" is the name of this feature. We tried bikeshedding it upthread, and didn't come up with anything better. If you're going to use a keyword related to the name "associated type", that leaves you with `associated`, `type`, or `associatedtype`.
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.
- Overly unclear. This is a very specific kind of type, not a generic type you can use in other contexts.
- 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.associated:
- Vacuous: doesn’t mean anything on its own: “associated Element”.
- Somewhat unfortunate as a keyword, but much less so than type.associatedtype:
- Clean in context: “associatedtype Element”
- Obvious you wouldn’t want to use it in another context.
- Googlable, unambiguous-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
"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…
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.
-Chris
On Dec 23, 2015, at 10:25 AM, Dave Abrahams <dabrahams@apple.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
--
Wizard
james@supmenow.com
+44 7523 279 698