Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

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 
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 requires
> a GenericTypeDelegate 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.
> 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?) 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 Array
>> {
>> func first() -> T?
>> }
>>
>> struct Node
>> {
>> var value: Value
>> }
>>
>> Array()
>> Node()
>>
>> or
>>
>> func makeACell() -> T
>> {
>> }
>>
>> makeACell()
>>
>> or
>>
>> protocol Collection
>> {
>> func first() -> Item?
>> }
>>
>> class IntBag : Collection //We bind protocol "associated type" using
>> generic syntax when subclassing. In this case we are saying Item should be
>> type Int
>> {
>> }
>>
>> class Array: Collection //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()
>>
>>
>> On Wed, Dec 23, 2015 at 10:58 PM, James Campbell 
>> 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 
>>> 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


>>>
>>>
>>> --
>>>  Wizard
>>> ja...@supmenow.com
>>> +44 7523 279 698
>>>
>>
>>
>>
>> --
>>  Wizard
>> ja...@supmenow.com
>> +44 7523 279 698
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Tino Heth via 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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Brent Royal-Gordon via 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 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

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

+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
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

In fact why not just use the generics syntax with protocols ?  Anybody
implementing a "Generic" Protocol has to specify the types.

protocol Collection
{

func get(key: Key) -> Value?
}

class StringCollection: Collection
{

}

class GenericCollection: Collection
{

}

On Wed, Dec 23, 2015 at 11:18 AM, James Campbell  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 //The T type placeholder is now an
> Int
> {
>
> }
>
> class GenericCollection: Collection //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
> ja...@supmenow.com
> +44 7523 279 698
>



-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Tino Heth via swift-evolution]

> 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 is naturally associated 
with an enumerator for Int — and it is no fun to be forced to include such 
relationships all over the place.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Craig Cruden via swift-evolution]

I prefer “type”.


> On 2015-12-23, at 20:05:46, Pierre Monod-Broca via swift-evolution 
>  wrote:
> 
> I would agree to stop talking about associated types and start talking about 
> placeholder types instead.
> But as a keyword, IMO the problem is that `placeholder` is not appropriate to 
> define the implementation.
> 
> eg
> class Foo: Stream {
> placeholder Payload = String // IMO doesn't feel right
> type Payload = String // IMO feels good
> }
> 
> -- 
> Pierre
> 
>> Le 23 déc. 2015 à 13:59, James Campbell > > a écrit :
>> 
>> I think we should use "placeholder" it more accurately describes what it 
>> does. For a bigger change then I would propose my protocol generics idea.
>> 
>> On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution 
>> > wrote:
>> +1 for `type`, it is consistent with `func`, `var` and `init`. It looks good 
>> to me.
>> 
>> eg:
>> 
>> protocol Stream {
>> type Payload
>> var ready: Bool { get }
>> func read() -> Payload?
>> }
>> 
>> protocol Collection {
>> type Element
>> var count: Int { get }
>> func contains(element: Element) -> Bool
>> }
>> 
>> 
>> -- 
>> Pierre
>> 
>>> Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution 
>>> > a écrit :
>>> 
>>> Hi,
>>> 
>>> I’m starting a new thread for this proposal 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>>>  
>>> 
>>> 
>>> So far, everybody agreed that using distinct keywords for type alias and 
>>> associated type declarations is a good idea.
>>> However, some people think that “associated” is not an ideal replacement 
>>> because it is too vague.
>>> I would like to choose a better keyword before the review, but I’m 
>>> struggling to find a good replacement. 
>>> 
>>> So, here are some keywords that were proposed by the community.
>>> 
>>> 1. associated_type
>>> This is the original proposed keyword. It is extremely clear, but 
>>> snake_cases are un-Swifty.
>>> 
>>> 2. associatedtype (or typeassociation)
>>> This was the first alternative to associated_type. Its purpose is still 
>>> extremely clear.
>>> I like it a lot, but it is a bit long and difficult to read.
>>> 
>>> 3. associated
>>> This is the keyword I chose for the proposal because it was the most 
>>> well-received initially. 
>>> It is quite short, very different from “typealias", and sounds good. 
>>> However, it is also vaguer.
>>> Because the word “type” is not in it, it’s unclear what should follow it, 
>>> and it’s unclear what it declares.
>>> For example, one could think that it is an associated *value* and write 
>>> protocol FixedSizeCollectionProtocol {
>>> associated size : Int
>>> }
>>> Although honestly I doubt many people would write that. 
>>> 
>>> 4. withtype (or needstype)
>>> It is short, somewhat easy to read, has the word “type” in it, and some 
>>> concept of association thanks to “with”. I like it. 
>>> But it doesn’t sound very good, and is still vaguer than “associatedtype”.
>>> 
>>> 5. type
>>> This keyword was proposed by several people, but I strongly dislike it.
>>> It conflicts with an other proposal about unifying the “static” and “class” 
>>> keywords for type-level members.
>>> I think the fact that it was proposed for two completely different purposes 
>>> shows that it is too abstract.
>>> It would make searching for help more difficult because of its bad 
>>> googleability.
>>> 
>>> 
>>> Personally, I would like to either keep “associated”, or use 
>>> “associatedtype” because they are the most obvious choices.
>>> 
>>> 1) Do you agree about using “associatedtype”?
>>> 2) If not, which keyword would you prefer to use? why? (you can introduce a 
>>> new one)
>>> Bonus) Maybe some twitter-famous person could make a quick poll and see 
>>> which one developers prefer?  (after they read this email)
>>> I would gladly do it myself, but I don’t think my twenty (mostly fake) 
>>> followers will give me a lot of information.  
>>> 
>>> Loïc
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> 
>> 
>> 
>> -- 
>>  Wizard
>> ja...@supmenow.com 
>> +44 7523 279 698
> 
> 
> 

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Sean Heber via swift-evolution]

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 
>  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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

If part of this proposal is to update documentation to refer to it as
"placeholder" typed then I am okay with "type"

On Wed, Dec 23, 2015 at 1:15 PM, Craig Cruden  wrote:

> I prefer “type”.
>
>
> On 2015-12-23, at 20:05:46, Pierre Monod-Broca via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I would agree to stop talking about associated types and start talking
> about placeholder types instead.
> But as a keyword, IMO the problem is that `placeholder` is not appropriate
> to define the implementation.
>
> eg
> class Foo: Stream {
> placeholder Payload = String // IMO doesn't feel right
> type Payload = String // IMO feels good
> }
>
> --
> Pierre
>
> Le 23 déc. 2015 à 13:59, James Campbell  a écrit :
>
> I think we should use "placeholder" it more accurately describes what it
> does. For a bigger change then I would propose my protocol generics idea.
>
> On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> +1 for `type`, it is consistent with `func`, `var` and `init`. It looks
>> good to me.
>>
>> eg:
>>
>> protocol Stream {
>> type Payload
>> var ready: Bool { get }
>> func read() -> Payload?
>> }
>>
>> protocol Collection {
>> type Element
>> var count: Int { get }
>> func contains(element: Element) -> Bool
>> }
>>
>>
>> --
>> Pierre
>>
>> Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>>
>> Hi,
>>
>> I’m starting a new thread for this proposal
>> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>>
>> So far, everybody agreed that using distinct keywords for type alias and
>> associated type declarations is a good idea.
>> However, some people think that “associated” is not an ideal replacement
>> because it is too vague.
>> I would like to choose a better keyword before the review, but I’m
>> struggling to find a good replacement.
>>
>> So, here are some keywords that were proposed by the community.
>>
>> 1. associated_type
>> This is the original proposed keyword. It is extremely clear, but
>> snake_cases are un-Swifty.
>>
>> 2. associatedtype (or typeassociation)
>> This was the first alternative to associated_type. Its purpose is still
>> extremely clear.
>> I like it a lot, but it is a bit long and difficult to read.
>>
>> 3. associated
>> This is the keyword I chose for the proposal because it was the most
>> well-received initially.
>> It is quite short, very different from “typealias", and sounds good.
>> However, it is also vaguer.
>> Because the word “type” is not in it, it’s unclear what should follow it,
>> and it’s unclear what it declares.
>> For example, one could think that it is an associated *value* and write
>> protocol FixedSizeCollectionProtocol {
>> associated size : Int
>> }
>> Although honestly I doubt many people would write that.
>>
>> 4. withtype (or needstype)
>> It is short, somewhat easy to read, has the word “type” in it, and some
>> concept of association thanks to “with”. I like it.
>> But it doesn’t sound very good, and is still vaguer than “associatedtype”.
>>
>> 5. type
>> This keyword was proposed by several people, but I strongly dislike it.
>> It conflicts with an other proposal about unifying the “static” and
>> “class” keywords for type-level members.
>> I think the fact that it was proposed for two completely different
>> purposes shows that it is too abstract.
>> It would make searching for help more difficult because of its bad
>> googleability.
>>
>>
>> Personally, I would like to either keep “associated”, or use
>> “associatedtype” because they are the most obvious choices.
>>
>> 1) Do you agree about using “associatedtype”?
>> 2) If not, which keyword would you prefer to use? why? (you can introduce
>> a new one)
>> Bonus) Maybe some twitter-famous person could make a quick poll and see
>> which one developers prefer?  (after they read this email)
>> I would gladly do it myself, but I don’t think my twenty (mostly fake)
>> followers will give me a lot of information.
>>
>> Loïc
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
>  Wizard
> ja...@supmenow.com
> +44 7523 279 698
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Pierre Monod-Broca via swift-evolution]

I would agree to stop talking about associated types and start talking about 
placeholder types instead.
But as a keyword, IMO the problem is that `placeholder` is not appropriate to 
define the implementation.

eg
class Foo: Stream {
placeholder Payload = String // IMO doesn't feel right
type Payload = String // IMO feels good
}

-- 
Pierre

> Le 23 déc. 2015 à 13:59, James Campbell  a écrit :
> 
> I think we should use "placeholder" it more accurately describes what it 
> does. For a bigger change then I would propose my protocol generics idea.
> 
> On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution 
> > wrote:
> +1 for `type`, it is consistent with `func`, `var` and `init`. It looks good 
> to me.
> 
> eg:
> 
> protocol Stream {
> type Payload
> var ready: Bool { get }
> func read() -> Payload?
> }
> 
> protocol Collection {
> type Element
> var count: Int { get }
> func contains(element: Element) -> Bool
> }
> 
> 
> -- 
> Pierre
> 
>> Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution 
>> > a écrit :
>> 
>> Hi,
>> 
>> I’m starting a new thread for this proposal 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>>  
>> 
>> 
>> So far, everybody agreed that using distinct keywords for type alias and 
>> associated type declarations is a good idea.
>> However, some people think that “associated” is not an ideal replacement 
>> because it is too vague.
>> I would like to choose a better keyword before the review, but I’m 
>> struggling to find a good replacement. 
>> 
>> So, here are some keywords that were proposed by the community.
>> 
>> 1. associated_type
>> This is the original proposed keyword. It is extremely clear, but 
>> snake_cases are un-Swifty.
>> 
>> 2. associatedtype (or typeassociation)
>> This was the first alternative to associated_type. Its purpose is still 
>> extremely clear.
>> I like it a lot, but it is a bit long and difficult to read.
>> 
>> 3. associated
>> This is the keyword I chose for the proposal because it was the most 
>> well-received initially. 
>> It is quite short, very different from “typealias", and sounds good. 
>> However, it is also vaguer.
>> Because the word “type” is not in it, it’s unclear what should follow it, 
>> and it’s unclear what it declares.
>> For example, one could think that it is an associated *value* and write 
>> protocol FixedSizeCollectionProtocol {
>>  associated size : Int
>> }
>> Although honestly I doubt many people would write that. 
>> 
>> 4. withtype (or needstype)
>> It is short, somewhat easy to read, has the word “type” in it, and some 
>> concept of association thanks to “with”. I like it. 
>> But it doesn’t sound very good, and is still vaguer than “associatedtype”.
>> 
>> 5. type
>> This keyword was proposed by several people, but I strongly dislike it.
>> It conflicts with an other proposal about unifying the “static” and “class” 
>> keywords for type-level members.
>> I think the fact that it was proposed for two completely different purposes 
>> shows that it is too abstract.
>> It would make searching for help more difficult because of its bad 
>> googleability.
>> 
>> 
>> Personally, I would like to either keep “associated”, or use 
>> “associatedtype” because they are the most obvious choices.
>> 
>> 1) Do you agree about using “associatedtype”?
>> 2) If not, which keyword would you prefer to use? why? (you can introduce a 
>> new one)
>> Bonus) Maybe some twitter-famous person could make a quick poll and see 
>> which one developers prefer?  (after they read this email)
>> I would gladly do it myself, but I don’t think my twenty (mostly fake) 
>> followers will give me a lot of information.  
>> 
>> Loïc
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> 
> -- 
>  Wizard
> ja...@supmenow.com 
> +44 7523 279 698

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Paul Cantrell via swift-evolution]

> On Dec 23, 2015, at 10:34 AM, Chris Lattner via swift-evolution 
>  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

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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Dave Abrahams via swift-evolution]

> On Dec 23, 2015, at 8:34 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Dec 23, 2015, at 2:08 AM, Brent Royal-Gordon via swift-evolution 
>>  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.

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



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Erica Sadun via swift-evolution]

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 
>  wrote:
> 
> 
>> On Dec 23, 2015, at 2:08 AM, Brent Royal-Gordon via swift-evolution 
>>  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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Dave Abrahams via swift-evolution]

> On Dec 23, 2015, at 12:41 PM, Chris Lattner  wrote:
> 
> On Dec 23, 2015, at 10:25 AM, Dave Abrahams  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.

Thanks for explaining, Chris.

-Dave



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Jordan Rose via swift-evolution]

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 
>  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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Dave Abrahams via swift-evolution]

> On Dec 23, 2015, at 2:51 PM, Matt Whiteside via swift-evolution 
>  wrote:
> 
> Just want to put 2 other ideas out there for completeness:
> 
> `relatedtype`
> 
> `componenttype`

My 2c: if we’re tack something onto “type”, the only appropriate modifier is 
“associated.”  “Associated type” isn’t a term we invented; it’s the correct 
accepted technical term for the role these declarations play in generic 
programming.

> 
>> On Dec 23, 2015, at 14:30, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Dec 23, 2015, at 1:53 PM, Michel Fortin via swift-evolution 
>>>  wrote:
>>> 
>>> inferredtype
>> 
>> It’s not always inferred, though.
>> 
>>  - Doug
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Chris Lattner via swift-evolution]

On Dec 23, 2015, at 10:25 AM, Dave Abrahams  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.

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

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  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
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Michel Fortin via swift-evolution]

inferredtype

-- 
Michel Fortin
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Kyle Carson via swift-evolution]

All of the options I've seen suffer from a common problem:  The order of 
parameters isn't obvious.  If we use an additional keyword we can have a more 
readable syntax.

Example using "associate" and "with":

associate *NewType* with *ExistingType*

Positives:
- Extremely clear, readable
- Relatively short syntax

Possible Negatives:
- May not be easy to Google
- Do multiple keywords fits Swift's general style?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

>
>
> > 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 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: Collection
{

}

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 = GenericCollection()

or

let items: [Int] = []

the Key and Value type placeholders would be Ints :) since the generic type
is an Int.


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[James Campbell via swift-evolution]

I think we should use "placeholder" it more accurately describes what it
does. For a bigger change then I would propose my protocol generics idea.

On Wed, Dec 23, 2015 at 12:50 PM, Pierre Monod-Broca via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 for `type`, it is consistent with `func`, `var` and `init`. It looks
> good to me.
>
> eg:
>
> protocol Stream {
> type Payload
> var ready: Bool { get }
> func read() -> Payload?
> }
>
> protocol Collection {
> type Element
> var count: Int { get }
> func contains(element: Element) -> Bool
> }
>
>
> --
> Pierre
>
> Le 19 déc. 2015 à 18:46, Loïc Lecrenier via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Hi,
>
> I’m starting a new thread for this proposal
> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
>
> So far, everybody agreed that using distinct keywords for type alias and
> associated type declarations is a good idea.
> However, some people think that “associated” is not an ideal replacement
> because it is too vague.
> I would like to choose a better keyword before the review, but I’m
> struggling to find a good replacement.
>
> So, here are some keywords that were proposed by the community.
>
> 1. associated_type
> This is the original proposed keyword. It is extremely clear, but
> snake_cases are un-Swifty.
>
> 2. associatedtype (or typeassociation)
> This was the first alternative to associated_type. Its purpose is still
> extremely clear.
> I like it a lot, but it is a bit long and difficult to read.
>
> 3. associated
> This is the keyword I chose for the proposal because it was the most
> well-received initially.
> It is quite short, very different from “typealias", and sounds good.
> However, it is also vaguer.
> Because the word “type” is not in it, it’s unclear what should follow it,
> and it’s unclear what it declares.
> For example, one could think that it is an associated *value* and write
> protocol FixedSizeCollectionProtocol {
> associated size : Int
> }
> Although honestly I doubt many people would write that.
>
> 4. withtype (or needstype)
> It is short, somewhat easy to read, has the word “type” in it, and some
> concept of association thanks to “with”. I like it.
> But it doesn’t sound very good, and is still vaguer than “associatedtype”.
>
> 5. type
> This keyword was proposed by several people, but I strongly dislike it.
> It conflicts with an other proposal about unifying the “static” and
> “class” keywords for type-level members.
> I think the fact that it was proposed for two completely different
> purposes shows that it is too abstract.
> It would make searching for help more difficult because of its bad
> googleability.
>
>
> Personally, I would like to either keep “associated”, or use
> “associatedtype” because they are the most obvious choices.
>
> 1) Do you agree about using “associatedtype”?
> 2) If not, which keyword would you prefer to use? why? (you can introduce
> a new one)
> Bonus) Maybe some twitter-famous person could make a quick poll and see
> which one developers prefer?  (after they read this email)
> I would gladly do it myself, but I don’t think my twenty (mostly fake)
> followers will give me a lot of information.
>
> Loïc
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Tino Heth via 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…
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Guillaume Lessard via swift-evolution]

> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution 
>  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
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Dave Abrahams via swift-evolution]

> On Dec 22, 2015, at 5:51 PM, Erica Sadun  wrote:
> 
>> 
>> On Dec 22, 2015, at 6:25 PM, Dave Abrahams > > wrote:
>> 
>>> 
>>> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution 
>>> > wrote:
>>> 
>>> 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
>  
> 
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 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
>>> 
>>> 
 On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution 
 > wrote:
 
 
> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution 
> > wrote:
> 
> When you're actually implementing a generic function, the generic 
> parameter is [snip]
 
 Here's a word with meaning: parameter. 

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Ross O'Brien via swift-evolution]

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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Dave Abrahams via swift-evolution]

> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 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?

> 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 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.

> 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. 
> 
> -- E
> 
> 
>> On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution 
>>> > 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 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Guillaume Lessard via swift-evolution]

> On 22 déc. 2015, at 19:01, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution 
>>  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.

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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Erica Sadun via swift-evolution]

> On Dec 22, 2015, at 6:25 PM, Dave Abrahams  wrote:
> 
>> 
>> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> 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 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


>> 
>> -- E
>> 
>> 
>>> On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution 
 > 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 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Andrey Tarantsov via 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.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Matt Whiteside via swift-evolution]

“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”.

Matt

> On Dec 22, 2015, at 07:40, Guillaume Lessard via swift-evolution 
>  wrote:
> 
> 
>> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution 
>>  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
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Loïc Lecrenier via swift-evolution]

Agreed for requiredtype. But I am not convinced “associatedtype” belabors the 
relationship between the protocol and the requirements. 

The word “associated” is never used as a replacement for “requirement”. It just 
names what the requirement is.
“[protocol] can only be used as a generic constraint because it has Self or 
__associated type requirements__”
“Grammar of a protocol __associated type__ declaration” (for comparison: 
“Grammar of a protocol __subscript__ declaration”)

(Counterpoint: maybe “associated” was only used there to avoid saying “type 
requirements/declaration”, which would be confusing)

I am now totally fine with “type”. But I am still afraid that it will be 
recycled elsewhere for a completely different purpose. Maybe that’s what you 
alluded to with “if we could make type work”? 

Anyway, it’s the holidays, and I don’t want to bother people with work. I think 
I will modify the proposal with a link to this discussion instead of “Community 
Responses”, and we’ll have three days right after the holidays to make a final 
choice :-)

Loïc

PS: here is the result of a survey asking developers which keyword they prefer: 
https://www.surveymonkey.com/results/SM-7L7WMQ3J/
2 people (out of 100) chose “other” and specified “type”. Sadly it wasn’t 
presented as an option, sorry :(


> On Dec 22, 2015, at 3:56 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 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.
> 
> -Joe

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Charles Kissinger via swift-evolution]

How about 'deferred’? As in one of the following:

typealias MyType = deferred

or:
deferredtype MyType

or:
deferred typealias MyType

(apologies if this was already suggested previously)

> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 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. 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 in CollectionType. 
> 
> 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. 
> 
> -- E
> 
> 
>> On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution 
>>> > 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 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Erica Sadun via swift-evolution]

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. 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 in CollectionType. 

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. 

-- E


> On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution 
>  wrote:
> 
> 
>> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution 
>>  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
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Matthew Johnson via swift-evolution]

> On Dec 22, 2015, at 11:30 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 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. 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 in CollectionType. 
> 
> 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. 

+1.  associatedtype seems better than any other option I’ve seen thus far 
(including the new ones you mentioned).

> 
> -- E
> 
> 
>> On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution 
>> > wrote:
>> 
>> 
>>> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution 
>>> > 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 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Matt Whiteside via swift-evolution]

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  wrote:
> 
> 
>> On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution 
>>  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
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Chris Lattner via swift-evolution]

> On Dec 20, 2015, at 8:27 AM, Stephen Celis via swift-evolution 
>  wrote:
> 
>> On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution 
>> > wrote:
>> 
>>> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> 
>>> I don't think `required` captures the intended meaning *at all*. You're not 
>>> required to declare the type of a "required typealias"—it's often, perhaps 
>>> even usually, inferred.
>> 
>> No, but it is required to exist and can't always be inferred.  It puts a 
>> constraint on the type that is declared to conform.  This is a requirement 
>> in exactly the same sense that other protocol requirements are requirements. 
>>  Notably operator requirements may be satisfied "implicitly" by declarations 
>> that already exist, but they are still requirements.
> 
> I think reusing "required" here (where "typealias" has already been reused) 
> could make the concept of associated types more opaque to new users.

I agree.  There are a couple of potentially confusing issues here:

- In principle, all of the declarations in the protocol are “requirements” that 
a type needs to fulfill to conform to the protocol.
- Except for optional requirements in @objc protocols.
- Except for requirements with default implementations (which currently cannot 
be written inline in the protocol, but should be allowed some day).  Today’s 
typealiases can have "default implementations” as well.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Michael Henson via swift-evolution]

Given that the type will/must be defined, implicitly or explicitly, by the
adopter of a protocol, what about "adopterType"?

Mike

On Mon, Dec 21, 2015 at 11:33 AM, Chris Lattner  wrote:

>
> On Dec 20, 2015, at 8:27 AM, Stephen Celis via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I don't think `required` captures the intended meaning *at all*. You're
> not required to declare the type of a "required typealias"—it's often,
> perhaps even usually, inferred.
>
>
> No, but it is required to exist and can't always be inferred.  It puts a
> constraint on the type that is declared to conform.  This is a requirement
> in exactly the same sense that other protocol requirements are
> requirements.  Notably operator requirements may be satisfied "implicitly"
> by declarations that already exist, but they are still requirements.
>
>
> I think reusing "required" here (where "typealias" has already been
> reused) could make the concept of associated types more opaque to new users.
>
>
> I agree.  There are a couple of potentially confusing issues here:
>
> - In principle, all of the declarations in the protocol are “requirements”
> that a type needs to fulfill to conform to the protocol.
> - Except for optional requirements in @objc protocols.
> - Except for requirements with default implementations (which currently
> cannot be written inline in the protocol, but should be allowed some day).
> Today’s typealiases can have "default implementations” as well.
>
> -Chris
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Dave Abrahams via swift-evolution]

> On Dec 21, 2015, at 4:57 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Dec 20, 2015, at 3:58 , Tino Heth via swift-evolution 
>> > wrote:
>> 
>> 
>>> The main reason to use `associated` is because the feature is called an 
>>> "associated type". If we're willing to rename the feature to "placeholder 
>>> type", then `placeholder` would be a good keyword.
>> good point - maybe it's because I'm no native speaker, but for me 
>> "associated type" is just a technical term with no obvious meaning.
> 
> Fair enough; "associated type" is a fairly vacuous term. I think the 
> implication is that when you choose a model of the protocol, the concrete 
> type, then these other types come along with it. But that's not immediately 
> clear, so I don't think renaming the feature is out of the question.
> 
> I don't like the name "placeholder" or "placeholder type" because that only 
> describes how they're used in the protocol. When you're actually implementing 
> a generic function, the generic parameter is a sort of placeholder, and the 
> associated types are just as concrete as the conforming type itself.

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.

-Dave



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Joe Groff via swift-evolution]

> On Dec 21, 2015, at 6:34 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 21, 2015, at 4:57 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Dec 20, 2015, at 3:58 , Tino Heth via swift-evolution 
>>> > wrote:
>>> 
>>> 
 The main reason to use `associated` is because the feature is called an 
 "associated type". If we're willing to rename the feature to "placeholder 
 type", then `placeholder` would be a good keyword.
>>> good point - maybe it's because I'm no native speaker, but for me 
>>> "associated type" is just a technical term with no obvious meaning.
>> 
>> Fair enough; "associated type" is a fairly vacuous term. I think the 
>> implication is that when you choose a model of the protocol, the concrete 
>> type, then these other types come along with it. But that's not immediately 
>> clear, so I don't think renaming the feature is out of the question.
>> 
>> I don't like the name "placeholder" or "placeholder type" because that only 
>> describes how they're used in the protocol. When you're actually 
>> implementing a generic function, the generic parameter is a sort of 
>> placeholder, and the associated types are just as concrete as the conforming 
>> type itself.
> 
> 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.

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.

-Joe

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Michel Fortin via swift-evolution]

Le 21 déc. 2015 à 21:34, Dave Abrahams via swift-evolution 
 a écrit :

> 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.

Could also use `typename`. But maybe that's too easy to mix with `typealias`.

-- 
Michel Fortin
michel.for...@michelf.ca
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Andrew Hoos via swift-evolution]

I second placeholder as the most rational keyword. Every description of the 
distinct usage of type alias refers to is a placeholder type. placeholder is 
one word(circumventingCase_issues) and is more descriptive of what it is than 
associated*. Seems like an easy win. Is there a some reason I am missing why 
*type* or associated* are better keyword fits?

Andrew Hoos

> On Dec 19, 2015, at 10:07, Tino Heth via swift-evolution 
>  wrote:
> 
>> snake_cases are un-Swifty
> amen.
> 
> My first thought for a name was "placeholder", and I just saw that this was 
> used in the description of the concept as well… so maybe this would be an 
> option?
> 
> Tino
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Tino Heth via swift-evolution]

> You even have a great keyword to search for, right there.
Good point - we are lucky that Apple has so much influence to make "swift" 
already a useful search term so we don't have to look for "swiftlang" ;-)
Still undecided wether this argument is a bad justification for cryptic names 
in general...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Tino Heth via swift-evolution]

> The main reason to use `associated` is because the feature is called an 
> "associated type". If we're willing to rename the feature to "placeholder 
> type", then `placeholder` would be a good keyword.
good point - maybe it's because I'm no native speaker, but for me "associated 
type" is just a technical term with no obvious meaning.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Loïc Lecrenier via swift-evolution]

-1
I understand the idea. But we would still need a replacement for “typealias” 
because “Element: typealias” says “Element is a type alias” and not “Element is 
an associated type”. 
Also, it would be difficult to add inheritance clauses and default values. 
“Element is an associated type that conforms to SequenceType, and is an Array 
of Int by default”
is currently
typealias Element : SequenceType = Array
but I don’t see how it could be written with your proposed syntax.

- Loïc

> On Dec 19, 2015, at 11:52 PM, Tino Heth <2...@gmx.de> wrote:
> 
> Another spontaneous idea (not sure weather I actually like it — take it as 
> brainstorming):
> Variable deklarations have the form
> thatIsTheName: ThatIsWhatIAm
> so the ambiguity could be resolved by
> ElementType: typealias
> which would say "ElementType is a associated type", like
> let i: Int
> says "i is an integer"

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Loïc Lecrenier via swift-evolution]

I like placeholder too.
However, it also suffers from the lack of “type” in it.

So, the real comparison is between:
placeholder — associated
placholdertype — associatedtype 

> On Dec 20, 2015, at 10:06 AM, Andrew Hoos  wrote:
> 
> I second placeholder as the most rational keyword. Every description of the 
> distinct usage of type alias refers to is a placeholder type. placeholder is 
> one word(circumventingCase_issues) and is more descriptive of what it is than 
> associated*. Seems like an easy win. Is there a some reason I am missing why 
> *type* or associated* are better keyword fits?
> 
> Andrew Hoos
> 
>> On Dec 19, 2015, at 10:07, Tino Heth via swift-evolution 
>>  wrote:
>> 
>>> snake_cases are un-Swifty
>> amen.
>> 
>> My first thought for a name was "placeholder", and I just saw that this was 
>> used in the description of the concept as well… so maybe this would be an 
>> option?
>> 
>> Tino
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Stephen Celis via swift-evolution]

> On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> I don't think `required` captures the intended meaning *at all*. You're not 
>> required to declare the type of a "required typealias"—it's often, perhaps 
>> even usually, inferred.
> 
> No, but it is required to exist and can't always be inferred.  It puts a 
> constraint on the type that is declared to conform.  This is a requirement in 
> exactly the same sense that other protocol requirements are requirements.  
> Notably operator requirements may be satisfied "implicitly" by declarations 
> that already exist, but they are still requirements.

I think reusing "required" here (where "typealias" has already been reused) 
could make the concept of associated types more opaque to new users.

The use of "typealias" as a kind of "typedef" immediately made sense to me. 
When I first stumbled upon "typealias" in a protocol, it took me some time to 
fully grok its use and its connection to its "typedef" counterpart.

Stephen___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Matthew Johnson via swift-evolution]

Sent from my iPhone

On Dec 19, 2015, at 2:17 PM, Michael Henson via swift-evolution 
 wrote:

>> 1) Do you agree about using “associatedtype”?
>> 2) If not, which keyword would you prefer to use? why? (you can introduce a 
>> new one)
> 
> There is another alternative. Rather than trying to come up with another 
> brand-new keyword, we can re-use one that has an existing and appropriate 
> meaning: required.
> 
> Example:
> 
> protocol ExampleProtocol {
>   required typealias Element
>   typealias MethodSignature = (arg: Element) -> Bool
> 
>   ... etc
> }
> 
> It's a little more verbose at the point of use but the declarations are 
> relatively uncommon and this usage is clearly separate from regular typealias 
> declarations.
> 

I don't link this as it's not entirely accurate.  Associated types are somewhat 
different than typealiases and are often inferred, not declared in the 
conforming types.

> Mike
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Dave Abrahams via swift-evolution]

> On Dec 19, 2015, at 12:17 PM, Michael Henson via swift-evolution 
>  wrote:
> 
> 1) Do you agree about using “associatedtype”?
> 2) If not, which keyword would you prefer to use? why? (you can introduce a 
> new one)
> 
> There is another alternative. Rather than trying to come up with another 
> brand-new keyword, we can re-use one that has an existing and appropriate 
> meaning: required.
> 
> Example:
> 
> protocol ExampleProtocol {
>   required typealias Element
>   typealias MethodSignature = (arg: Element) -> Bool
> 
>   ... etc
> }
> 
> It's a little more verbose at the point of use but the declarations are 
> relatively uncommon and this usage is clearly separate from regular typealias 
> declarations.


I think this is a big improvement over associatedtype, except that the type 
that satisfies the requirement needn't be a typealias.  I would therefore 
prefer "requiredtype."

-Dave



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Michael Henson via swift-evolution]

>
> 1) Do you agree about using “associatedtype”?
> 2) If not, which keyword would you prefer to use? why? (you can introduce
> a new one)


There is another alternative. Rather than trying to come up with another
brand-new keyword, we can re-use one that has an existing and appropriate
meaning: required.

Example:

protocol ExampleProtocol {
  required typealias Element
  typealias MethodSignature = (arg: Element) -> Bool

  ... etc
}

It's a little more verbose at the point of use but the declarations are
relatively uncommon and this usage is clearly separate from regular
typealias declarations.

Mike
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Stephen Christopher via swift-evolution]

I like “requiredtype”.

Step Christopher
Big Nerd Ranch, LLC
schristop...@bignerdranch.com


On Sat, Dec 19, 2015 at 3:54 PM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Dec 19, 2015, at 12:17 PM, Michael Henson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 1) Do you agree about using “associatedtype”?
>> 2) If not, which keyword would you prefer to use? why? (you can introduce
>> a new one)
>
>
> There is another alternative. Rather than trying to come up with another
> brand-new keyword, we can re-use one that has an existing and appropriate
> meaning: required.
>
> Example:
>
> protocol ExampleProtocol {
>   required typealias Element
>   typealias MethodSignature = (arg: Element) -> Bool
>
>   ... etc
> }
>
> It's a little more verbose at the point of use but the declarations are
> relatively uncommon and this usage is clearly separate from regular
> typealias declarations.
>
>
> I think this is a big improvement over associatedtype, except that the
> type that satisfies the requirement needn't be a typealias.  I would
> therefore prefer "requiredtype."
>
> -Dave
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Brent Royal-Gordon via swift-evolution]

> There is another alternative. Rather than trying to come up with another 
> brand-new keyword, we can re-use one that has an existing and appropriate 
> meaning: required.
> 
> Example:
> 
> protocol ExampleProtocol {
>   required typealias Element
>   typealias MethodSignature = (arg: Element) -> Bool
> 
>   ... etc
> }
> 
> It's a little more verbose at the point of use but the declarations are 
> relatively uncommon and this usage is clearly separate from regular typealias 
> declarations.

I don't think `required` captures the intended meaning *at all*. You're not 
required to declare the type of a "required typealias"—it's often, perhaps even 
usually, inferred. On the other hand, all types conforming to ExampleProtocol 
are "required" in some sense to have an Element, but they're also "required" to 
have a MethodSignature. (In fact, they're required to have exactly the 
MethodSignature specified there, but they can have any Element they want.) It's 
just not a good match.

If you wanted to analogize associated types to some existing feature, it would 
clearly be generics (but this is not done for very good reasons). If you wanted 
to reuse an existing keyword at all costs, I suspect what you should actually 
do is mark the non-associated type with `final` (but this doesn't match 
typealiases in other types, and it doesn't solve the searchability problem with 
using "typealias" for associated types).

The whole reason we got into this mess is because we unwisely reused a keyword 
for something barely related. Let's not do it again.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Kelly Gerber via swift-evolution]

I believe Scala uses just “type” for abstract type members. Is that too short? 
If too short, then how about “typemember”? Or perhaps “abstractype”?

-Kelly

> Hi,
> 
> I’m starting a new thread for this proposal 
> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
> 
> So far, everybody agreed that using distinct keywords for type alias and 
> associated type declarations is a good idea.
> However, some people think that “associated” is not an ideal replacement 
> because it is too vague.
> I would like to choose a better keyword before the review, but I’m struggling 
> to find a good replacement. 
> 
> So, here are some keywords that were proposed by the community.
> 
> 1. associated_type
> This is the original proposed keyword. It is extremely clear, but snake_cases 
> are un-Swifty.
> 
> 2. associatedtype (or typeassociation)
> This was the first alternative to associated_type. Its purpose is still 
> extremely clear.
> I like it a lot, but it is a bit long and difficult to read.
> 
> 3. associated
> This is the keyword I chose for the proposal because it was the most 
> well-received initially. 
> It is quite short, very different from “typealias", and sounds good. However, 
> it is also vaguer.
> Because the word “type” is not in it, it’s unclear what should follow it, and 
> it’s unclear what it declares.
> For example, one could think that it is an associated *value* and write 
> protocol FixedSizeCollectionProtocol {
>   associated size : Int
> }
> Although honestly I doubt many people would write that. 
> 
> 4. withtype (or needstype)
> It is short, somewhat easy to read, has the word “type” in it, and some 
> concept of association thanks to “with”. I like it. 
> But it doesn’t sound very good, and is still vaguer than “associatedtype”.
> 
> 5. type
> This keyword was proposed by several people, but I strongly dislike it.
> It conflicts with an other proposal about unifying the “static” and “class” 
> keywords for type-level members.
> I think the fact that it was proposed for two completely different purposes 
> shows that it is too abstract.
> It would make searching for help more difficult because of its bad 
> googleability.
> 
> 
> Personally, I would like to either keep “associated”, or use “associatedtype” 
> because they are the most obvious choices.
> 
> 1) Do you agree about using “associatedtype”?
> 2) If not, which keyword would you prefer to use? why? (you can introduce a 
> new one)
> Bonus) Maybe some twitter-famous person could make a quick poll and see which 
> one developers prefer?  (after they read this email)
> I would gladly do it myself, but I don’t think my twenty (mostly fake) 
> followers will give me a lot of information.  
> 
> Loïc
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Dave Abrahams via swift-evolution]

> On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> There is another alternative. Rather than trying to come up with another 
>> brand-new keyword, we can re-use one that has an existing and appropriate 
>> meaning: required.
>> 
>> Example:
>> 
>> protocol ExampleProtocol {
>>  required typealias Element
>>  typealias MethodSignature = (arg: Element) -> Bool
>> 
>>  ... etc
>> }
>> 
>> It's a little more verbose at the point of use but the declarations are 
>> relatively uncommon and this usage is clearly separate from regular 
>> typealias declarations.
> 
> I don't think `required` captures the intended meaning *at all*. You're not 
> required to declare the type of a "required typealias"—it's often, perhaps 
> even usually, inferred.

No, but it is required to exist and can't always be inferred.  It puts a 
constraint on the type that is declared to conform.  This is a requirement in 
exactly the same sense that other protocol requirements are requirements.  
Notably operator requirements may be satisfied "implicitly" by declarations 
that already exist, but they are still requirements.

> On the other hand, all types conforming to ExampleProtocol are "required" in 
> some sense to have an Element, but they're also "required" to have a 
> MethodSignature. (In fact, they're required to have exactly the 
> MethodSignature specified there, but they can have any Element they want.)

No, that is not a protocol requirement; it doesn't put a constraint on any type 
that is declared to conform.

> It's just not a good match.
> 
> If you wanted to analogize associated types to some existing feature, it 
> would clearly be generics (but this is not done for very good reasons). If 
> you wanted to reuse an existing keyword at all costs, I suspect what you 
> should actually do is mark the non-associated type with `final` (but this 
> doesn't match typealiases in other types, and it doesn't solve the 
> searchability problem with using "typealias" for associated types).
> 
> The whole reason we got into this mess is because we unwisely reused a 
> keyword for something barely related. Let's not do it again.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Erica Sadun via swift-evolution]

> Maybe [some person] could make a quick poll and see which one developers 
> prefer?  (after they read this email)

Ask. Receive.

https://www.surveymonkey.com/r/S8F59XF 



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Jacob Bandes-Storch via swift-evolution]

Am I too late to throw in more off-the-cuff suggestions?

protocol SequenceType {
having Generator
}

protocol SequenceType { }   // in the protocol signature,
but distinct from a generic param

protocol SequenceType // same idea


Jacob Bandes-Storch

On Sat, Dec 19, 2015 at 8:37 PM, Kelly Gerber via swift-evolution <
swift-evolution@swift.org> wrote:

> I believe Scala uses just “type” for abstract type members. Is that too
> short? If too short, then how about “typemember”? Or perhaps “abstractype”?
>
> -Kelly
>
> > Hi,
> >
> > I’m starting a new thread for this proposal
> https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md
> >
> > So far, everybody agreed that using distinct keywords for type alias and
> associated type declarations is a good idea.
> > However, some people think that “associated” is not an ideal replacement
> because it is too vague.
> > I would like to choose a better keyword before the review, but I’m
> struggling to find a good replacement.
> >
> > So, here are some keywords that were proposed by the community.
> >
> > 1. associated_type
> > This is the original proposed keyword. It is extremely clear, but
> snake_cases are un-Swifty.
> >
> > 2. associatedtype (or typeassociation)
> > This was the first alternative to associated_type. Its purpose is still
> extremely clear.
> > I like it a lot, but it is a bit long and difficult to read.
> >
> > 3. associated
> > This is the keyword I chose for the proposal because it was the most
> well-received initially.
> > It is quite short, very different from “typealias", and sounds good.
> However, it is also vaguer.
> > Because the word “type” is not in it, it’s unclear what should follow
> it, and it’s unclear what it declares.
> > For example, one could think that it is an associated *value* and write
> > protocol FixedSizeCollectionProtocol {
> >   associated size : Int
> > }
> > Although honestly I doubt many people would write that.
> >
> > 4. withtype (or needstype)
> > It is short, somewhat easy to read, has the word “type” in it, and some
> concept of association thanks to “with”. I like it.
> > But it doesn’t sound very good, and is still vaguer than
> “associatedtype”.
> >
> > 5. type
> > This keyword was proposed by several people, but I strongly dislike it.
> > It conflicts with an other proposal about unifying the “static” and
> “class” keywords for type-level members.
> > I think the fact that it was proposed for two completely different
> purposes shows that it is too abstract.
> > It would make searching for help more difficult because of its bad
> googleability.
> >
> >
> > Personally, I would like to either keep “associated”, or use
> “associatedtype” because they are the most obvious choices.
> >
> > 1) Do you agree about using “associatedtype”?
> > 2) If not, which keyword would you prefer to use? why? (you can
> introduce a new one)
> > Bonus) Maybe some twitter-famous person could make a quick poll and see
> which one developers prefer?  (after they read this email)
> > I would gladly do it myself, but I don’t think my twenty (mostly fake)
> followers will give me a lot of information.
> >
> > Loïc
> >
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution