Sent from my iPhone
On 15 May 2016, at 15:05, Brent Royal-Gordon via swift-evolution
<[email protected]> wrote:
>> There we are. I read the declaration of the function from beginning to end
>> and gradually formed a rough understanding of it without needing to change
>> my expectations halfway through. I still have doubts about 'insertCount',
>> but I was at least able to formulate an hypothesis about its use.
>>
>> YMMV, but as far as I'm concerned, the original declaration was much easier
>> to understand.
>
> I actually agree with you for this case, but not *all* type information *has*
> to be moved to the end. Try this on for size, which is actually still the
> most natural way to write this declaration in SE-0081:
>
> internal func _arrayOutOfPlaceReplace
> <B: _ArrayBufferProtocol, C: Collection>
> (_ source: inout B, _ bounds: Range<Int>, _ newValues: C, _ insertCount: Int)
> where
> C.Iterator.Element == B.Element,
> B.Index == Int
> {
>
> Now only the relatively unimportant details—that the buffer and collection
> must have elements of the same type, and that the buffer must have integer
> indices—are at the end, whereas the basic conformances required to make any
> sense at all of the declaration are still inline.
>
> This proposal *permits* you to hollow out the generic parameter list to the
> point of vacuousness, but that doesn't mean it's the right thing to do. It
> might make sense to ban a direct `X: Foo` requirement unless there was
> already an `X: Bar` in the generic parameter list. Or we might simply need to
> paraphrase the Perl manual page: "There are several ways to write a generic
> requirement, so consider picking the most readable one."
I think you hit the nail on the head. Being able to let the developer decide
how to place relevant type information with the freedom of being able to keep
some/all/none type information local and some/none/all extra information moved
to the end of the declaration. Don't we allow the same kind of freedom with
protocols and extensions in a way?
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
