> 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.
To be clear, I do think it makes sense to move *all* `where` clauses to the end
of the parameter list, not allow them both within the angle brackets and at the
end of the definition. And I'm not convinced it makes sense to support moving
all conformance information to the `where` clause, either. A generic parameter
list like `<T, U>` is vacuous; when you're dealing with something like this:
public func transcode
<Input: IteratorProtocol, InputEncoding: UnicodeCodec,
OutputEncoding: UnicodeCodec>
(_ input: Input, from inputEncoding: InputEncoding.Type, to
outputEncoding: OutputEncoding.Type, stoppingOnError stopOnError: Bool,
sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void)
-> Bool
where InputEncoding.CodeUnit == Input.Element
The detail in the `where` clause really is of secondary importance, especially
compared to how much syntax it takes to specify, while this:
public func transcode
<Input, InputEncoding, OutputEncoding>(_ input: Input, from
inputEncoding: InputEncoding.Type, to outputEncoding: OutputEncoding.Type,
stoppingOnError stopOnError: Bool, sendingOutputTo processCodeUnit: @noescape
(OutputEncoding.CodeUnit) -> Void) -> Bool
where Input: IteratorProtocol, InputEncoding: UnicodeCodec,
OutputEncoding: UnicodeCodec, InputEncoding.CodeUnit == Input.Element
Leaves far too much unspecified until the end.
I'm actually tempted to suggest that a conformance should be *mandatory* and
you should have to specify `Any` if you don't have anything more specific to
say about the generic parameter:
func map<T: Any>(@noescape transform: (Element) throws -> T) rethrows
-> [T]
That would penalize the "leave everything until the end" style without actually
introducing any arbitrary rules forbidding it.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
