[swift-evolution] [Review] SE-0081: Move where clause to end of declaration
panajev at gmail.com
Sun May 15 09:17:54 CDT 2016
Sent from my iPhone
On 15 May 2016, at 15:05, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> 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)
> 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
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution