The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
What is your evaluation of the proposal?
+1, originally I hadn’t seen the value, but ran into wanting this just the other day.
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?
Very much so.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
NA
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Pretty brief, read through the proposal early on and was reaching for this functionality a few days ago.
···
On Mar 24, 2016, at 9:54 AM, Douglas Gregor <dgregor@apple.com> wrote:
Hello Swift community,
The review of SE-0048 "Generic Type Aliases" begins now and runs through March 29, 2016. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
That's my biggest question about this proposal. Yes, as the proposal
says, generic type aliases fill an obvious functional gap. But what
real-world problems are they solving and why should adding them be a
priority?
···
on Thu Mar 24 2016, Douglas Gregor <dgregor-AT-apple.com> wrote:
Hello Swift community,
The review of SE-0048 "Generic Type Aliases" begins now and runs through March 29, 2016. The proposal is available here:
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the
direction of Swift. When writing your review, here are some questions
you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change
to Swift?
What is your evaluation of the proposal?
+1. Especially for forcing the alias side of the declaration to explicitly keep track of type constraints.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Previously, one could "work around" this by declaring a 0-case generic enum with associated type "projections". I'm glad to see that pattern find a formal place in the language.
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
This proposal brings Swift up to par with languages that allow any kind of "alias"ing of types, whether that be C++ or Haskell [in a cleaner way than the former].
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study. I actually took a crack at an implementation a while ago!
~Robert Widmann
2016/03/24 12:54、Douglas Gregor via swift-evolution <swift-evolution@swift.org> のメッセージ:
···
Hello Swift community,
The review of SE-0048 "Generic Type Aliases" begins now and runs through March 29, 2016. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
What is your evaluation of the proposal?
A strong +1 on this.
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?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study, I ran into a situation where I needed something like this some time ago.
···
On Mar 24, 2016, at 1:54 PM, Douglas Gregor <dgregor@apple.com> wrote:
Hello Swift community,
The review of SE-0048 "Generic Type Aliases" begins now and runs through March 29, 2016. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
- What is your evaluation of the proposal?
- Is the problem being addressed significant enough to warrant a
change to Swift?
- Does this proposal fit well with the feel and direction of Swift?
- If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about the Swift evolution process is available at
- Is the problem being addressed significant enough to warrant a
change to Swift?
Yes, it is a limitation of the current language that you can't do this.
You can get round the limitation using a struct but type alias is a neater
solution.
- Does this proposal fit well with the feel and direction of Swift?
Yes, you would naturally expect this to be possible
- If you have 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 think it's a good idea that will make a lot of code clearer.
I agree with the decision not to support additional constraints on the generic type. Typealiases should be just what it says in the name: aliases. It should not be possible to constrain a type with a typealias in a way you could not by substituting the same type name in directly.
In other words, I don't think this:
typealias ComparableArray<T where T : Comparable> = Array<T>
Makes any more sense than this:
Array<T where T: Comparable>
• Is the problem being addressed significant enough to warrant a change to Swift?
Yes. The "proposed solution" examples are all quite sensible.
• Does this proposal fit well with the feel and direction of Swift?
Yes.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I haven't used any such languages enough to ever use an equivalent feature.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Strong +1 from me, too. With the exact response as Juan. It is among the top 10 on my wish list.
···
On Mar 24, 2016, at 11:18 AM, Juan Ignacio Laube via swift-evolution <swift-evolution@swift.org> wrote:
What is your evaluation of the proposal?
A strong +1 on this.
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?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study, I ran into a situation where I needed something like this some time ago.
On Mar 24, 2016, at 1:54 PM, Douglas Gregor <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
Hello Swift community,
The review of SE-0048 "Generic Type Aliases" begins now and runs through March 29, 2016. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the
direction of Swift. When writing your review, here are some questions
you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change
to Swift?
That's my biggest question about this proposal. Yes, as the proposal
says, generic type aliases fill an obvious functional gap. But what
real-world problems are they solving and why should adding them be a
priority?
Is the problem being addressed significant enough to warrant a change
to Swift?
That's my biggest question about this proposal. Yes, as the proposal
says, generic type aliases fill an obvious functional gap. But what
real-world problems are they solving
They allow you to make aliases for generic types, e.g. from the document:
It is an inconsistency in the language that you can create aliases for non-generic types, but that you can’t make them for generic ones. Perhaps you are objecting to typealias as a feature at all?
and why should adding them be a priority?
It is part of the general goal of completing the generics system, a stated Swift 3 goal.
-Chris
···
On Mar 24, 2016, at 1:18 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I think it is a very important feature to enable working with more complicated generic types while maintaining readability.
I do not agree with the decision not to support additional constraints on the generic type. I do have the strong feeling that this would be useful. At the moment it is not more than a feeling, though, without a compelling example, and as it can easily be added later I'm fine with a first implementation as proposed.
• Is the problem being addressed significant enough to warrant a change to Swift?
Yes, definitely.
• Does this proposal fit well with the feel and direction of Swift?
Yes.
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Haskell has generic typealiases which are quite commonly used.
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Personally I find typealias useful for giving a friendly name to long types
and informative names to types in general. This applies to generic types as
much as non-generic, e.g.:
That's my biggest question about this proposal. Yes, as the proposal
says, generic type aliases fill an obvious functional gap. But what
real-world problems are they solving and why should adding them be a
priority?
To give a motivating example, we ported a streaming library that involved a highly generic type called Proxy<A, B, X, Y, R> (here https://github.com/typelift/Aquifer/blob/master/Aquifer/Proxy.swift#L62\) that is built in such a way that its various generic aliases (written below in the enum's typealiases) impart upon it completely different semantics and use cases depending on how the underlying type is specialized. Without generic aliases, we're forced to use the hacks in that linked file and expose methods that suggest a particular semantics by reaching for the right enum and asking for the respective typealias. This way, we can cut out the middle man and just get on with it.
So, even if this feature weren't here there is still a way to do it in the language as it stands. But for something that is so obviously a gap in the implementation, not including it seems a waste, don't you think?
~Robert Widmann
2016/03/29 0:28、Chris Lattner via swift-evolution <swift-evolution@swift.org> のメッセージ:
···
On Mar 24, 2016, at 1:18 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
Is the problem being addressed significant enough to warrant a change
to Swift?
That's my biggest question about this proposal. Yes, as the proposal
says, generic type aliases fill an obvious functional gap. But what
real-world problems are they solving
They allow you to make aliases for generic types, e.g. from the document:
It is an inconsistency in the language that you can create aliases for non-generic types, but that you can’t make them for generic ones. Perhaps you are objecting to typealias as a feature at all?
and why should adding them be a priority?
It is part of the general goal of completing the generics system, a stated Swift 3 goal.
Is the problem being addressed significant enough to warrant a change
to Swift?
That's my biggest question about this proposal. Yes, as the proposal
says, generic type aliases fill an obvious functional gap. But what
real-world problems are they solving
They allow you to make aliases for generic types, e.g. from the document:
I know what the feature allows. What I don't see is any burning need
for it.
It is an inconsistency in the language that you can create aliases for
non-generic types, but that you can’t make them for generic ones.
Perhaps you are objecting to typealias as a feature at all?
I'm not objecting at all. It's an obvious thing for us to do, and we
should do it at some point. It just doesn't seem very impactful or
crucial.
and why should adding them be a priority?
It is part of the general goal of completing the generics system, a
stated Swift 3 goal.
True. I just wonder if we should be frying bigger fish.
···
on Mon Mar 28 2016, Chris Lattner <clattner-AT-apple.com> wrote:
On Mar 24, 2016, at 1:18 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I use typealiases as a form of documentation for an API, not just for convenience. The fact that Xcode parses the doc comments on them is also quite useful.
Russ
···
On Mar 29, 2016, at 10:14 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I'm not objecting at all. It's an obvious thing for us to do, and we
should do it at some point. It just doesn't seem very impactful or
crucial.