Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

+1 from me including the preference for "associated" instead of "associatedtype" -Thorsten Am 03.01.2016 um 19:10 schrieb Alex Migicovsky via swift-evolution : >> * What is your evaluation of the proposal? > > I think the proposal is great. The only thing I’d

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

> * What is your evaluation of the proposal? +1. Solves a real problem I’ve come across before. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes, because the problem can cause serious frustration, for beginners in particular. > *

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

>>* What is your evaluation of the proposal? +1 >>* Is the problem being addressed significant enough to warrant a change >> to Swift? Definitely. This is very confusing to have typealias mean two different things. >>* Does this proposal fit well with the feel and direction of

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

On Sun, Jan 3, 2016, at 03:41 AM, Loïc Lecrenier via swift-evolution wrote: > Hi Drew, > > Thanks for the review, just a quick remark: > > “Real” type aliases are already forbidden inside protocols, so this proposal > wouldn’t change that. > (According to the grammar, a protocol body can only

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

Hi Drew, Thanks for the review, just a quick remark: “Real” type aliases are already forbidden inside protocols, so this proposal wouldn’t change that. (According to the grammar, a protocol body can only contain: property, method, initializer, subscript, or associated type member declarations)

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

> On 03 Jan 2016, at 07:38, Douglas Gregor wrote: > > * What is your evaluation of the proposal? I am in favor of this for the same reasons mentioned by the previous reviewers. > * Is the problem being addressed significant enough to warrant a change > to

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

> * What is your evaluation of the proposal? I think the proposal is great. The only thing I’d prefer is to use `associated` over `associatedtype`. `associated` has always felt better to me over `associatedtype`. It was mentioned in one of the original proposals as the keyword that was

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

I have one concern with `associated` vs `associatedtype`, which is that it people might, in the interest of clarity, start naming things using a conventions like `associated PayloadType`, when I think it would be better to have `associatedtype Payload` because it leaves less room for

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

Sorry for the previous message. I pressed “Send” by mistake... Here is my +1: > * What is your evaluation of the proposal? It’s a great improvement. > * Is the problem being addressed significant enough to warrant a change > to Swift? Definitely. > * Does this proposal fit

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

On Sat, Jan 2, 2016, at 10:38 PM, Douglas Gregor wrote: > * What is your evaluation of the proposal? +1 I have a preference for `associated` instead of `associatedtype`, but it's not a big deal. > * Is the problem being addressed significant enough to warrant a > change to Swift? Personally I