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

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 >

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

> 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

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

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

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

+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

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

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

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

> 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

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

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

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

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.

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

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

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

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

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

> 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

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

> 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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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"

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 -

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

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

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

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

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

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

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

> 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

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

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

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

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,

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

> 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

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

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,

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

> 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

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

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

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

> 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

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

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

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

> 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

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

> 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

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

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

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

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

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

> 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

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

> 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

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

-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

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

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

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

> 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

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

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

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

> 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

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

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

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

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>

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

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

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

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 >

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

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

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

> 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

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

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