One thing to keep in mind is that, if I recall correctly, some members of the core team have expressed a desire to enhance `throws` by letting users list the specific error types that a function can throw. If that is something that might happen in the future, moving the `throws/throwing` to the front would add a significant amount of noise before the function name.
On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution < [email protected]> wrote: > I agree that this could do with revision. It looks particularly ugly when > you’re dealing with throwing closures. > > Recently I had a signature like: > > public func scan(length: File.ByteOffset.Stride?, > by frameSize: File.ByteOffset.Stride, > with handler: > (_ range: Range<File.ByteOffset>, _ data: UnsafeRawBufferPointer) throws -> > Bool) throws -> File.ByteOffset.Stride > > It can get difficult to parse the signature towards the end. Marking the > handler and function as throwing closer to the beginning would make it more > readable IMO. One thing it allows me to do more easily is to remove the > spaces around the arrow for the closure parameter (just a little thing > which I find helps me read the trailing closure/return type more quickly). > > public throwing func scan(length: File.ByteOffset.Stride?, > by > frameSize: File.ByteOffset.Stride, > with handler: throwing > (_ range: Range<File.ByteOffset>, _ data: UnsafeRawBufferPointer)->Bool) > -> File.ByteOffset.Stride > > - Karl > > On 26 Dec 2016, at 18:38, thislooksfun via swift-evolution < > [email protected]> wrote: > > Hello Swifters, > > I've been writing a lot more Swift code recently, and I have found that > the default placement of the 'throws' declaration is often confusing, > especially to those of us switching from languages where the type of errors > thrown is explicitly defined (like Java) > > For example, > > // This is pretty clear, this can throw an error > func foo() throws > { ... } > > // Also pretty clear, this returns a String > func bar() -> String > { ... } > > // Confusing. Does this throw a String? Does it return a String? Does it do > both? > // I personally keep reading this as 'this can throw a String' > func baz() throws -> String > > // Equivalent code in Java (not a model, just for clarification of why the > above is confusing) > String baz() throws StringFormatException > > I therefore suggest either tweaking the syntax around, or moving, the > `throws` keyword to avoid this confusion. > > Some ideas I've had: > > // Add a comma to separate them > func baz() throws, -> String > > // Move `throws` to the end > func baz() -> String throws > > // Change it to a prefix modifier (like `mutating`) > throwing func baz() -> String > > I'm still not sold on any of the above syntaxes, but I would love to hear > your feedback. > > This would affect existing code, but it would be a fairly small change > that would result in very large readability improvements, especially for > newcomers, and *especially* for those coming for a language such as Java. > > -thislooksfun (tlf) > > _______________________________________________ > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
