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 > <swift-evolution@swift.org> 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
