Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

I’m sorry, I was misusing the 80/20 principle there, not making an argument that 80% of all types are trivially Equatable (though I would assert the number types that are trivially Equatable would be far greater than those that are not). I was merely stating that the rare cases in which

Re: [swift-evolution] [Proposal] Protected Access Level

Unless I'm missing something Brent, your suggestions still wouldn't allow the developer to provide a public class in a module designed to be subclassed by clients in another module and access these "private" details, which is a real problem I'm having in my current project. I have a framework

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Thanks for replying Chris! > On 29 May 2016, at 6:00 AM, Chris Lattner wrote: > > 2) If a value wants a better, or more customized, string form, then it > conforms to CustomStringConvertible. What are the use cases for this more customized string form? If it is for the

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Yeah I don’t see a problem. It’s the same way that protocol extensions just work. Think of this automatic synthesis as a really flexible protocol extension: extension Hashable where Members : Hashable { var hashValue : Int { return self.allMembers.reduce(^) // Or whatever combiner is best

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

That's quite the assertion you make. What's your evidence that 80% of the time an Equatable type is 'trivially' equatable? In stdlib? Foundation? If you could demonstrate that it's really the case, I'd probably be inclined to support default synthesis of conformance to Equatable. On Sat, May 28,

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

New proposal looks great. I love how this brings more consistency with how normal statements are written. It would be nice to see in the proposal examples of before & afters for `while` too. Especially as it says "where clauses are no longer used to conjoin Boolean expressions with conditional

Re: [swift-evolution] [Pitch] #warning

#warning isn't exclusively used for FIXMEs. Languages that include these kinds of features do things like flag old modules or unsupported OSes and older Swift versions by combining it with #if - a feature Swift implements far richer conditionals for than other languages I might add. The kinds

Re: [swift-evolution] [Pitch] #warning

I can see where you're coming from, but I don't necessarily see this as "warnings which can then be ignored." In my vision, this enables developers to increase visibility of known issues, instead of letting them sit. Developers who would normally use this feature to add their own warnings are

Re: [swift-evolution] [Pitch] #warning

I appreciate the sentiment, but I think we should reserve warnings for actual compiler diagnostics. If you wish to add another, user definable diagnostic type, like official compiler support for a #todo or #fixme flag, then go ahead. But adding #warning because the IDE (read Xcode)

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> The problem with this is that it doesn’t differentiate between synthesized > and manual conformance. You won’t get error messages you otherwise would > when you intend to supply manual conformance. It is also less clear to a > reader of the code that the default, compiler synthesized

Re: [swift-evolution] [Pitch] Circling back to `with`

> On May 28, 2016, at 9:29 PM, Brent Royal-Gordon > wrote: > >>> You are trying to call `mutating` methods on an *immutable* value, the >>> return value of `withCopy`. Normally, the compiler would reject that. >> >> You are right, there would need to be an exception

Re: [swift-evolution] Variadic generics discussion

> On May 28, 2016, at 3:03 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolution, > > I put together a draft proposal for the variadic generics feature described > in "Completing Generics" as a major objective for Swift 3.x. It can be found >

Re: [swift-evolution] [Pitch] Circling back to `with`

>> You are trying to call `mutating` methods on an *immutable* value, the >> return value of `withCopy`. Normally, the compiler would reject that. > > You are right, there would need to be an exception for method cascades. That > might be a reasonable exception to make because we already know

Re: [swift-evolution] [Pitch] Circling back to `with`

> On May 27, 2016, at 7:19 PM, Brent Royal-Gordon > wrote: > >>> - A plain `with` whose closure parameter is not mutable and which is marked >>> `@discardableResult`. >> >> I would like to see this version restricted to AnyObject. It has extremely >> limited utility

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

> On May 28, 2016, at 8:43 PM, Pedro Vieira via swift-evolution > wrote: > > I really think this would be a great addition to Swift. Although, I don't see > the need to use a new keyword `deriving` for this feature. > The following would be enough: > > struct Foo:

Re: [swift-evolution] Variadic generics discussion

I appreciate your feedback! Some thoughts inline... > On May 28, 2016, at 3:22 PM, Xiaodi Wu wrote: > > Some initial thoughts, from a guy who doesn't remember his C++ very well: > > * The motivation for using prefix ... at declaration and postfix ... > elsewhere seems

Re: [swift-evolution] [Proposal] Protected Access Level

To begin with, I'm not a fan of `protected` access. But even leaving that aside, I have a few questions and critiques. > A common case is the UIView from UIKit. Many developers are tempted to make > this call: > > view.layoutSubviews() > The documentation says: "You should not call this method

Re: [swift-evolution] Variadic generics discussion

Thanks for your feedback! > On May 28, 2016, at 3:21 PM, Daniel Vollmer via swift-evolution > wrote: > > I’ve only taken a short glance at this (and just like the proposal, I’m > damaged by C++11, so my opinion is biased), so here are some thoughts: > - I’d prefer

[swift-evolution] [Pitch] #warning

Hey everyone, I’m working on a draft for #warning in Swift. I’ve implemented the draft as it stands, and it’s pretty nice to work with. I’ve pasted it below, and I’d love some feedback! Thanks! — Harlan Haskins #warning Proposal: SE-

Re: [swift-evolution] [Proposal] Protected Access Level

If we're to introduce the protected visibility, I think we should as well make it automatically internal or introduce an explicit protected internal visibility. I've been through many cases while programming in C# 'where' this was handy (thou I cannot name one from memory right now; it's been

Re: [swift-evolution] [Proposal] Protected Access Level

Seems entirely reasonable to me. POP aficionados may object, but I think the pros and cons of this type of access are well trodden terrain and I think it's a net win to have this available in Swift going forward. On Sat, May 28, 2016 at 18:53 Vanderlei Martinelli via swift-evolution <

[swift-evolution] [Proposal] Protected Access Level

Hello. This is the first draft. I'd like to know your opinion about it. (I know that this subject could have been discussed before. If so, please indicate me the correct thread to follow and interact.) Regards, Vanderlei Martinelli --- Introduction Protected access level will enable

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

> On May 27, 2016, at 12:11 PM, Joe Groff 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: > > >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> If anyone is curious, the revised proposal can be found here: > https://github.com/austinzheng/swift-evolution/blob/2b31df6163f5c5d1975a37e72c6996b82d61a5c6/proposals/0089-rename-string-reflection-init.md This is great. My only suggestion is that `init?(description: String)` should be

Re: [swift-evolution] Variadic generics discussion

Erm, autocorrect deserves credit for converting 'tuple' to 'triple.' Sorry. On Sat, May 28, 2016 at 18:22 Xiaodi Wu wrote: > Some initial thoughts, from a guy who doesn't remember his C++ very well: > > * The motivation for using prefix ... at declaration and postfix ... >

Re: [swift-evolution] Variadic generics discussion

Some initial thoughts, from a guy who doesn't remember his C++ very well: * The motivation for using prefix ... at declaration and postfix ... elsewhere seems lacking in this proposal; is this necessary in Swift? If so, why? If not, can we stick with one or the other? * There's going to be some

Re: [swift-evolution] Variadic generics discussion

Hi, > On 28 May 2016, at 22:03, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolution, > > I put together a draft proposal for the variadic generics feature described > in "Completing Generics" as a major objective for Swift 3.x. It can be found >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

Thanks! The PR I submitted earlier should have an updated version of the proposal which takes most of your feedback into account. I'll amend it later to address the rest. Sent from my iPhone > On May 28, 2016, at 1:33 PM, Chris Lattner wrote: > > >> On May 27, 2016, at

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

>> - Abusing rawValue is just that: an abuse. > > My original proposal does not replace rawValue and is compatible with it. `rawValue` has a different purpose from how you're using it. It's supposed to allow you to convert your type to some other *equivalent* type, like an equivalent integer

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

> On May 28, 2016, at 12:13 AM, Patrick Smith via swift-evolution > wrote: > A different train of thought: could semicolons allow the closure ambiguity to > be resolved that Chris brought up a couple of months ago? e.g. > I imagine it wouldn’t, as the parser would

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

> On May 28, 2016, at 12:07 PM, Thorsten Seitz wrote: > > What about requiring `let` before each binding and `case` before each pattern? > > guard case let x = a, case let y = b, let z = c, x == y else { … } > > Now `let z = c` can only be a let-binding and not a pattern

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> On May 27, 2016, at 8:51 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolution, > > I've put together a preliminary v2 of the proposal, taking into account > feedback expressed on this thread. I would appreciate any comments, > suggestions, or

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

I've submitted a swift-evolution PR with a modified version of the proposal that takes into account the feedback from the discussion participants. If anyone is curious, the revised proposal can be found here:

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

I'm not sure how feasible this is...but why not remove the conditional case to remove the ambiguity? Conditional case seems somewhat esoteric compared to the current behavior that many people are used to. (I.e. How many know of and use a conditional case?) Is it worth de-beautifying the syntax

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 28, 2016, at 2:31 PM, Thorsten Seitz via swift-evolution > wrote: > > I’m not happy with that restriction in the proposal: > > Existentials cannot be used with generics in the following ways: > > In generic declarations, with the requirements composed out

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

On May 26, 2016, at 9:40 PM, Austin Zheng via swift-evolution wrote: >> Some remaining open questions: >> >> - Exactly what types should conform to ValuePreservingStringConvertible. It >> seems clear that integer, floating point types, and Character can and should

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On 28 May 2016, at 20:16, Xiaodi Wu wrote: > > I couldn't disagree more. Generic programming is a far more advanced concept > than arrays and dictionaries, and learners should be able to use them without > contending with angle brackets they don't understand. > >

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

I'm just gotta quote from Advanced Swift: Note that the where clause [in a for loop] does not work like the where clause in a while loop. In a while loop, iteration stops once the value is false, whereas in a for loop, it functions like filter. On Sat, May 28, 2016 at 16:00 Haravikk

[swift-evolution] Variadic generics discussion

Hello swift-evolution, I put together a draft proposal for the variadic generics feature described in "Completing Generics" as a major objective for Swift 3.x. It can be found here: https://github.com/austinzheng/swift-evolution/blob/az-variadic-generics/proposals/-variadic-generics.md It

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

On May 27, 2016, at 9:10 PM, Jacob Bandes-Storch via swift-evolution wrote: > Does "lossless" preclude floating-point numbers from being printed in decimal > unless they are exactly representable? No, FP types should be able to conform. There are algorithms that are

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

> On 28 May 2016, at 20:21, Xiaodi Wu wrote: > > There's already an inconsistency in where clause behavior for `if` and > `while` versus `for` loops. It's nice IMO that the former uses are eliminated > in this proposal. Can you give an example? That sounds like something

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> On May 27, 2016, at 7:50 PM, Patrick Smith via swift-evolution > wrote: > > Is there any possibility we can break from this? Especially as: > > 1. ValuePreservingStringConvertible expects its description to be value > preserving, but current Cocoa implementations

Re: [swift-evolution] [Proposal] Enums with static storedpropertiesfor each case

So it should either be an exception when using tuples (which I know is not good) or ensure the combination of values in all tuple values are different from one another. -Original Message- From: "Jānis Kiršteins" Sent: ‎28/‎05/‎2016 03:58 PM To: "Leonardo

Re: [swift-evolution] Enhanced existential types proposal discussion

Two more minor things: - The wording of that section should be amended to make it clear that the current behavior (existentials with exactly one requirement and no constraints are allowed to satisfy totally unconstrained generic type parameters) continues to be allowed. - Unfortunately, even if

Re: [swift-evolution] Enhanced existential types proposal discussion

There are a couple of reasons why it's not possible. - You can't force A and B to be protocols (forcing them to be protocols is distinct from forcing them to be types that implement a certain protocol). If you pass in two concrete types "Any" becomes invalid. - If a generic type has any

Re: [swift-evolution] Enhanced existential types proposal discussion

I’m not happy with that restriction in the proposal: Existentials cannot be used with generics in the following ways: In generic declarations, with the requirements composed out of generic type variables: // NOT ALLOWED func foo(x: A, y: B) -> Any { ... } Why is that not allowed?

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

Sent from my iPad > On May 28, 2016, at 12:33 PM, Chris Lattner wrote: > > >> On May 28, 2016, at 10:18 AM, Matthew Johnson wrote: >> Given the whole newline groundswell that has emerged on SE, I did consider it but when I mocked

Re: [swift-evolution] [Review] SE-0097: Normalizing naming for "negative" attributes

I meant writing a proposal for having noescape be the default with an `@escaping` attribute to have different behavior. `@once` would be a separate proposal and looks to be out of scope for Swift 3.0. The former change was mentioned by Chris Lattner in

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

Sent from my iPad > On May 28, 2016, at 1:38 PM, Haravikk via swift-evolution > wrote: > > >> On 27 May 2016, at 15:31, plx via swift-evolution >> wrote: >> >> protocol Sequence { >> typealias of == S: Self where

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

Sent from my iPad > On May 28, 2016, at 12:40 PM, Thorsten Seitz wrote: > > >>> Am 27.05.2016 um 20:47 schrieb Matthew Johnson via swift-evolution >>> : >>> >>> On May 27, 2016, at 12:05 PM, Charles Srstka via swift-evolution

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

• What is your evaluation of the proposal? +1 • Is the problem being addressed significant enough to warrant a change to Swift? Yes. I have often been frustrated by needing to break up conditions to make complex checks. I am not completely sure that this proposal addresses that issue but it is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Sent from my iPad > On May 28, 2016, at 12:50 PM, Thorsten Seitz wrote: > > >> Am 28.05.2016 um 19:35 schrieb Austin Zheng : >> >> Sorry, 'with' in the second example should be 'where'. My personal >> preference is to keep 'where' for both uses,

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

There's already an inconsistency in where clause behavior for `if` and `while` versus `for` loops. It's nice IMO that the former uses are eliminated in this proposal. Again, whether declaring multiple variables after a single let is a good idea or not is, I think, out of scope for this proposal.

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

> Am 28.05.2016 um 20:28 schrieb Haravikk via swift-evolution > : > >> On 27 May 2016, at 20:11, Joe Groff via swift-evolution >> > wrote: >> >> • What is your evaluation of the proposal? > >

Re: [swift-evolution] [Proposal] Enums with static stored propertiesfor each case

As previosly state there is one problem using tuples as rawValues - they currently must be static (literals) and unique. In example with planets the mass or radius is not unique so it cannot be used as raw value with current requirments. > On 28 May 2016, at 20:22, Leonardo Pessoa

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

> On 27 May 2016, at 20:11, Joe Groff via swift-evolution > wrote: > > • What is your evaluation of the proposal? Uncertain. I understand the intent behind it, but personally I really like the where clause as it covers most cases where I need to mix and match,

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> Am 27.05.2016 um 20:47 schrieb Matthew Johnson via swift-evolution > : > > >> On May 27, 2016, at 12:05 PM, Charles Srstka via swift-evolution >> > wrote: >> >>> On May 27, 2016, at 9:31 AM, plx via

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Sorry, 'with' in the second example should be 'where'. My personal preference is to keep 'where' for both uses, since they are serving the same purpose. > On May 28, 2016, at 10:33 AM, Austin Zheng wrote: >> >> -Thorsten > > We could make parentheses optional in the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On May 28, 2016, at 10:26 AM, Thorsten Seitz wrote: > > Austin raised the point (or reminded of Joe’s raising the point) of possible > problems when returning constrained existentials from generic functions: > > func foo(p: P, q: Q) -> any where P: > Equatable {

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

> On May 28, 2016, at 10:18 AM, Matthew Johnson wrote: > >>> >>> Given the whole newline groundswell that has emerged on SE, I did consider >>> it but when I mocked up examples, it felt less readable and I suspect it >>> would negatively affect the clarity of parsing

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

> On May 27, 2016, at 4:35 PM, Brent Royal-Gordon via swift-evolution > wrote: > I am not a fan of this syntax. `;` reads very strongly as a statement ender > to me, Technically speaking, Swift uses semicolon as a separator, not a line ender. We already use it to

Re: [swift-evolution] [Proposal] Enums with static stored propertiesfor each case

My suggestion of allowing tuples as raw values instead doesn't burden the language and also does not eliminate rawValue (treat previously supported raw value types as one value tuples), reads very cleanly and supports a syntax we're already familiar with. I don't see how the 'where' syntax

Re: [swift-evolution] [Review] SE-0097: Normalizing naming for "negative" attributes

I agree with Jose. I especially like the idea of making `@noescape` the default with a new `@escaping` attribute. As I believed was mentioned in an earlier review, this would also make the proposed `@noescape(once)` just be `@once`. I'd be happy to write the proposal for that rename. On Wed, May

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

Sent from my iPad > On May 28, 2016, at 12:11 PM, Chris Lattner wrote: > > On May 27, 2016, at 12:37 PM, Erica Sadun via swift-evolution > wrote: On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution

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

On May 27, 2016, at 12:37 PM, Erica Sadun via swift-evolution wrote: >> On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution >> wrote: >>> • What is your evaluation of the proposal? >> >> +1. I believe it improves the

[swift-evolution] No access to list of environment variables possible from within Swift

Hello, Currently there is no list of environment variables visible from within a Swift program. You can use `getenv` and `setenv` from the C Standard library to access a variable of which you know the name, but sometimes that’s not enough. One simple case is when using `posix_spawn` to

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

Perhaps, but it is a much bigger change and a different proposal topic entirely. Given how variable declarations work now, Erica's proposed syntax to replace where clauses is the most elegant solution, IMO. On Sat, May 28, 2016 at 04:15 Goffredo Marocchi via swift-evolution <

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Sent from my iPad > On May 27, 2016, at 10:08 PM, Patrick Smith via swift-evolution > wrote: > > A different way of layering could be allowing value types to be composed, > where the outer type inherits the inner member’s properties and methods. > > Let’s say you

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I’m a +1 to this, this is something that keeps catching me out as I’m so used to omitting return in other closures, and that’s essentially all a computer property is anyway so it makes sense for the behaviour to be consistent. > On 27 May 2016, at 18:57, Adrian Zubarev via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

> On May 28, 2016, at 7:49 AM, Xiaodi Wu via swift-evolution > wrote: > > I don't recall whether it was in this thread or another that this point was > made by the core team, but if I'm remembering correctly: it was shared that > the protocol is now called

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

-1 I like the original design for the fact that it does not give "description", which nobody would have proposed Swift had started as a blank slate, center stage: promoting it to protocol membership would perpetuate something that people should no longer be focussing on. So although I do

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

I'll write a small proposal tomorrow for that behavior (not only for computed properties of course)! Today I'm too busy. Thank you for your positive feedback. -- Adrian Zubarev Sent with Airmail Am 28. Mai 2016 um 10:11:26, David Hart (da...@hartbit.com(mailto:da...@hartbit.com))

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

This I would not cry about. In other languages they are more of a source of pain than anything else. Sent from my iPhone > On 28 May 2016, at 09:10, David Hart via swift-evolution > wrote: > > Yet another alternative: would it be possible to disallow commas as

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now. > On 28 May 2016, at 09:03, Brian Christensen via swift-evolution > wrote: > > On May 27, 2016, at 13:57, Adrian Zubarev via

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

Yet another alternative: would it be possible to disallow commas as variable declaration separators and use them for condition clause separators again: let a = 4, b = 8 // becomes illegal and requires to separate them on two lines if a > 4, let c = foo(), let d = bar(), c != d { // now comma is

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

Agreed! Sent from my iPhone > On 28 May 2016, at 08:10, L. Mihalkovic via swift-evolution > wrote: > > >> On May 28, 2016, at 2:30 AM, Erica Sadun via swift-evolution >> wrote: >> >> On May 27, 2016, at 6:26 PM, Brent

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

+1. This has always tripped me up, I guess I felt there was a good reason for requiring you to add a `return`, but not sure what it would be. > On 28 May 2016, at 3:57 AM, Adrian Zubarev via swift-evolution > wrote: > > The idea is simple: > > Can we make return

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

> On 28 May 2016, at 10:37 AM, Matthew Johnson via swift-evolution > wrote: > > But I don't know what that has to do with the fact that newline can be used > as an alternative. It's just an alternate separator. As far as I know, > everywhere semicolons are used as

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

> On May 28, 2016, at 2:30 AM, Erica Sadun via swift-evolution > wrote: > > >>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon >>> wrote: >>> >>> guard >>> x == 0 && a == b && c == d && >>> let y = optional, w = optional2, v = optional 3

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution wrote: > The idea is simple: > > • Can we make return keyword optional in cases like this? > • Shouldn’t this behave like @autoclosure or @noescape? > type A { > var characters: [Character]

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

> Let me answer in another way that speaks to my background which isn't in > compiler theory: The use of && may produce cognitive overload between the use > in Boolean assertions and the use in separating condition clauses. Yes, which is quite intentional on my part. The `if` statement requires

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

Golang has IMO successfully used this in their IF statement. Coming from a recent imersion into the language, it is not as distracting in real life code on a day to day basis, as it might seem to be when first seen in a spec. Considering the parallel with the swift guard, this is IMO a nice