[swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

Haravikk swift-evolution at haravikk.me
Mon May 30 05:40:29 CDT 2016


> On 29 May 2016, at 20:39, Chris Lattner <clattner at apple.com> wrote:
> 
>> On May 29, 2016, at 3:55 AM, Haravikk <swift-evolution at haravikk.me <mailto:swift-evolution at haravikk.me>> wrote:
>>>> On May 27, 2016, at 12:11 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>>>> 
>>>> Hello Swift community,
>>>> 
>>>> The review of SE-0099 “Restructuring Condition Clauses” begins now and runs through June 3, 2016. The proposal is available here:
>>>> 
>>>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>
>>> Thanks everyone.  FYI, Erica and I discussed it offlist and agreed to amend the proposal: now you can use semicolons or a newline to separate clauses of different types.
>> 
>> While I like the improvements made to the proposal, I’m still not in favour of removing the where clause; the introduction of semi-colons and new-lines as separators eliminates the need to use it if you don’t want to, so developers will be free to drop it if they wish, but I don’t see any real reason to remove it from the syntax, as it feels inconsistent if I can use it elsewhere, and I prefer to do so, particularly on if/guard.
> 
> I can definitely respect the position that “where” feels more readable than a semicolon, it certainly provides a more “fluent” style.
> 
> That said, the existing Swift 2 syntax was inconsistent about this too: if you started a condition with an availability check, you comma separate it from a boolean with a comma:
> 
> 	if #available(iOS 52, *), x == y {} 
> 
> While we could have used “where” here, it was counterproductive because it didn’t increase clarity of code.

See I never write statements like these. In fact, I almost never write conditionals that aren’t something like the following:

	if foo && (bar == “bar”) { … }
	if let value = foo { … }
	if let value = foo where value > 5 { … }
	if #available(iOS 52, *) { … }

I’m starting to use pattern matching more, but I only found out about the existence of that feature relatively recently as a result of subscribing to this list ;)

Point being that the third case is the only one where I ever do any real mixing and matching. Of course I can’t guarantee that I’ll never need something more complex some day, but I’ve managed pretty well so far without running into problems.

> On 29 May 2016, at 15:15, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> Haravikk, this *is* the proposal for removing where clauses; changing the rules about commas was the later addition to the discussion.

Still, I feel like these are two different issues, as I’m generally in favour of the switch to semi-colon separators (though I do prefer how commas look, but that’s minor as I almost never use them, and mostly for binding multiple values which looks like it will still be able to use commas anyway), but I’m very fond of using where for the mixing and matching.

I understand that the need for semi-colon separators probably arose as a requirement of removing where, but I think it makes more sense to cover semi-colons first as a result, and come back to removing where clauses afterwards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160530/fce0bb2d/attachment.html>


More information about the swift-evolution mailing list