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

[Thorsten Seitz via swift-evolution]

+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 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 initially 
> most well received as well—I think this is because it just feels right, which 
> is a good indicator even though it doesn’t seem scientific :-)
> 
> One downside mentioned is that `associated` is more vague than 
> `associatedtype`, but there’s a reason why we don’t have `protocoltype`, 
> `classtype`, etc as keywords over `protocol` and `class`. I think the 
> convention of having associated type names start with an uppercase letter 
> makes it clear that what follows `associated` is a type (or will be a 
> concrete type).
> 
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> Yes, I’ve seen many developers be confused by the difference between defining 
> a typealias inside a protocol declaration vs outside.
> 
>> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes.
> 
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> I’ve been paying attention to the thread and have thought about why I like 
> `associated` over `associatedtype` since the start of the thread.
> 
> - Alex
> ___
> 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] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Sebastian Hagedorn via swift-evolution]

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

>   * Does this proposal fit well with the feel and direction of Swift?

Yes, because readability is improved. No need to consider the context anymore, 
the keyword itself makes it very clear what is declared.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

I haven’t used any language with a comparable feature.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 

I’ve read the review carefully and followed the prior discussion briefly.

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

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

[Rod Brown via swift-evolution]

>>* 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 Swift?
Yes. While it does add something, it simplifies and removes confusion.

>>* If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
I haven't used similar features in other languages.

>>* How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
Read the review, run into the problem myself, and followed the discussion here.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Ballard via swift-evolution]

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 contain: property, 
> method, initializer, subscript, or associated type member declarations)
> 
> In your example, secondstype and usecstype were associated types with initial 
> values. To convince yourself, try to create this function
> func bar(_: Foo) { }
> and you should see the "can only be used as a generic constraint because it 
> has Self or associated type requirements” error.
> 
> I initially wanted to allow type aliases inside protocols, and I was told 
> type aliases weren’t requirements, so they shouldn’t be defined inside 
> protocols, which makes sense to me.
> 
> We might want to reconsider this, but I think it is outside the scope of this 
> proposal.

I agree that protocols shouldn't have typealiases, but I would be in favor of 
protocol extensions having them:

extension SequenceType {
typealias Element = Generator.Element
}

But it is definitely outside the scope of this proposal.

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

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

[Loïc Lecrenier via swift-evolution]

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)

In your example, secondstype and usecstype were associated types with initial 
values. To convince yourself, try to create this function
func bar(_: Foo) { }
and you should see the "can only be used as a generic constraint because it has 
Self or associated type requirements” error.

I initially wanted to allow type aliases inside protocols, and I was told type 
aliases weren’t requirements, so they shouldn’t be defined inside protocols, 
which makes sense to me.

We might want to reconsider this, but I think it is outside the scope of this 
proposal.

Loïc

> On Jan 3, 2016, at 11:46 AM, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
>> 
>>  * What is your evaluation of the proposal?
> 
> +1
> 
>>  * Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes.  A typealias in a protocol and a typealias anywhere else are 2 very 
> different things.
> 
> * One is almost a preprocessor macro
> * The other basically defines the protocol as a generic type, which has a lot 
> of strange follow-on consequences
> 
> There are plenty of questions online related to this confusion.
> 
> In addition the change is trivial and code could be transitioned 
> automatically.
> 
>>  * Does this proposal fit well with the feel and direction of Swift?
> 
> The choice of keyword "associatedtype" is already used in a common compiler 
> error message:
> 
>> protocol 'Printable' can only be used as a generic constraint because it has 
>> Self or associated type requirements
> 
> Using "associatedtype" here is consistent with that error message and makes 
> it more understandable for new users.
> 
>>  * If you have you used other languages or libraries with a similar 
>> feature, how do you feel that this proposal compares to those?
> 
> I am an occasional user of Rust; Rust uses the same keyword ("type") in both 
> of these cases.  IMO that choice is suffers from the same problems in Rust 
> that it does here.
> 
>>  * How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> One "potential" problem with this proposal is that it technically forbids the 
> use of a "real" typealias in a protocol e.g.
> 
> protocol Foo {
> typealias F = Int
> }
> 
> is now illegal.
> 
> To evaluate the severity of this problem I checked a private codebase with 47 
> usages of typealias.  One usage of the 47 would be illegal:
> 
> protocol Foo {
> #if arch(x86_64) || arch(arm64)
> typealias secondstype = Int64
> typealias usecstype = Int64
>   #else
> typealias secondstype = __darwin_time_t
> typealias usecstype = __darwin_suseconds_t
>#endif
>   func setTimeout(s: secondstype, u: usecstype) throws
> }
> 
> I refactored this to move the typealiases to top level.  That is not ideal, 
> but I think it is outweighed by the advantages of this proposal.
> 
> While auditing this codebase for illegal typealiases I did find a comment 
> that was quite confused about the difference between typealias and 
> associatedtype.  So that convinces me even more about the importance of this 
> proposal.
> 
> ___
> 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] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Janosch Hildebrand via swift-evolution]

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

Yes.

>   * Does this proposal fit well with the feel and direction of Swift?

I think so. 

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

I am only aware of Rust and I haven't used that enough to make any meaningful 
comparisons.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I read the proposal and followed the previous threads discussing the proposal 
and the keyword.

Speaking of which, `associatedtype` remains my favorite. I don't think its 
ideal but I prefer it to the alternatives that were considered.

> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
>   Cheers,
>   Doug Gregor
>   Review Manager
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

- Janosch

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

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

[Alex Migicovsky via swift-evolution]

> * 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 initially 
most well received as well—I think this is because it just feels right, which 
is a good indicator even though it doesn’t seem scientific :-)

One downside mentioned is that `associated` is more vague than 
`associatedtype`, but there’s a reason why we don’t have `protocoltype`, 
`classtype`, etc as keywords over `protocol` and `class`. I think the 
convention of having associated type names start with an uppercase letter makes 
it clear that what follows `associated` is a type (or will be a concrete type).

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes, I’ve seen many developers be confused by the difference between defining a 
typealias inside a protocol declaration vs outside.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I’ve been paying attention to the thread and have thought about why I like 
`associated` over `associatedtype` since the start of the thread.

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

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

[Matt Whiteside via swift-evolution]

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 interpretation about how to name things 
idiomatically.

But I still haven’t completely decided between `type` and `associatedtype`, and 
I plan to respond to this thread separately with my thoughts on that.

Matt


> On Jan 3, 2016, at 10:10, Alex Migicovsky via swift-evolution 
>  wrote:
> 
>> * 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 initially 
> most well received as well—I think this is because it just feels right, which 
> is a good indicator even though it doesn’t seem scientific :-)
> 
> One downside mentioned is that `associated` is more vague than 
> `associatedtype`, but there’s a reason why we don’t have `protocoltype`, 
> `classtype`, etc as keywords over `protocol` and `class`. I think the 
> convention of having associated type names start with an uppercase letter 
> makes it clear that what follows `associated` is a type (or will be a 
> concrete type).
> 
>> * Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> Yes, I’ve seen many developers be confused by the difference between defining 
> a typealias inside a protocol declaration vs outside.
> 
>> * Does this proposal fit well with the feel and direction of Swift?
> 
> Yes.
> 
>> * How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> I’ve been paying attention to the thread and have thought about why I like 
> `associated` over `associatedtype` since the start of the thread.
> 
> - Alex
> ___
> 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] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

[Rudolf Adamkovič via swift-evolution]

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 well with the feel and direction of Swift?

Yes.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

No.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

I followed the discussion closely.

—

Rudolf Adamkovic

R+

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

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

[Kevin Ballard via swift-evolution]

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 don't think it's a particularly significant problem, but it
is a small one that this change would help with, and the change itself
is pretty minor (and can be automated in 100% of cases).

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?

Rust has the same feature, although it uses the keyword `type` instead
of `typealias`. And they still use the same keyword `type` for
associated types inside of traits. But rust uses associated types much
more sparingly than Swift does (Rust traits can have generic type
parameters, and in fact associated types were a fairly late addition to
the language). Swift is also much more of a teaching language than Rust
is, so I think this change is quite reasonable for Swift.

> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?

I followed the original swift-evolution thread and read the proposal
again just now.

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