> On 10 May 2016, at 19:51, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
> * What is your evaluation of the proposal?
I’m a +1, however personally I’d prefer this to be optional my constraints
aren’t that complex, for example:
func someMethod<T where T.Element == String>(value:T) { … }
Personally I prefer to keep such simple cases as they are, but would happily
use the new ability to move more complex ones (e.g- dealing with
Generator.Element and multiple constraints) to the end as proposed.
So I’m +1, but I don’t think it should be one or the other, I’d prefer to have
both options, with a recommendation that trailing constraints be used in
complex cases for clarity.
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Generic constraints are one of the most powerful, and daunting, features of
Swift, so anything that makes them a bit neater and keeps function signatures
tidy is an improvement. Of course there’s a lot more that can be done to
simplify generic constraints further, but given the simple elegance of this
improvement it easily justifies inclusion.
> * Does this proposal fit well with the feel and direction of Swift?
I’d say yes, since the feature itself is unchanged and already part of Swift,
it’s just the location that is being moved.
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
Quick read through, which is plenty since the proposal is fairly
straightforward, I’ve also been following the discussion for a while._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
