Hello!
* What is your evaluation of the proposal?
+1, due to the already stated reasons: difference in meanings, better
expression of the associated types construct etc. I also do like the
`associatedtype` keyword proposal and I’ve yet to see any better alternatives
in the discussion.
* Is the problem being addressed significant enough to warrant a change to
Swift?
Yes. The change reflects the gravity of the problem, which is limited in terms
of source-compatibility, but significant in terms of programmers’ understanding
and being beginners friendly.
* Does this proposal fit well with the feel and direction of Swift?
I do feel so. Looking at already posted „Swift philosophy” summary: "Provide a
programmer model that: is high level; is expressive and clean” I believe the
change makes the high-level concept of associated types expressive and clean in
the code.
* If you have you used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
I’ve been using „abstract type members” in Scala traits, which are a very
similar concept. Frankly, I believe that Swift „associated type” naming is less
confusing than „abstract type”. Also, Scala uses „type” keyword with is not
descriptive enough for me. Again, I like „associatedtype” better.
* How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
I’ve been closely following the discussion(s) on the swift-evolution list and
I’ve read the proposal. While I haven't done any in-depth literature study,
I’ve been cross-comparing the proposed solution with my knowledge/experience in
Scala.
Cheers,
Krzysztof Siejkowski
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
