Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 17, 2016, at 12:35 AM, Slava Pestov wrote: > > >> On Aug 16, 2016, at 10:16 PM, Charles Srstka > > wrote: >> >>> On Aug 16, 2016, at 11:42 PM, Slava Pestov >> > wrote: Argh, that’s particularly frustrating since in s

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 10:16 PM, Charles Srstka wrote: > >> On Aug 16, 2016, at 11:42 PM, Slava Pestov > > wrote: >>> >>> Argh, that’s particularly frustrating since in something like ‘func foo>> P>(t: T)’ or ‘func foo(s: S) where S.IteratorElement: P’, >>> you’re only

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 11:42 PM, Slava Pestov wrote: >> >> Argh, that’s particularly frustrating since in something like ‘func foo> P>(t: T)’ or ‘func foo(s: S) where S.IteratorElement: P’, >> you’re only ever getting instances anyway since the parameter is in the >> input, so calling initialize

Re: [swift-evolution] [Discussion] Sortable Attribute

On Tue, Aug 16, 2016 at 11:31 PM, Charlie Monroe wrote: > My original intention was to get rid of re-defining what should be the > sequence sorted by. For example, if self.sorted { $0.age < $1.age } was at > 10 places in code, I would not consider it a good coding technique and > would definitely

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 8:52 PM, Charles Srstka wrote: > >> On Aug 16, 2016, at 8:51 PM, Slava Pestov > > wrote: >> >> Here is why we must have that requirement. Consider the following code: >> >> protocol P { >> init() >> } >> >> struct A : P { >> init() {} >> } >

Re: [swift-evolution] Swift for bare-metal programming

> On Aug 17, 2016, at 2:47 AM, Anton Zhilin via swift-evolution > wrote: > > 2016-08-17 3:27 GMT+03:00 Roderick Mann >: > >> There's also the need to be able to name a specific physical (perhaps > >> virtual) memory address and do bit operations on them. In C/C++

Re: [swift-evolution] [Discussion] Sortable Attribute

My original intention was to get rid of re-defining what should be the sequence sorted by. For example, if self.sorted { $0.age < $1.age } was at 10 places in code, I would not consider it a good coding technique and would definitely suggest the person to create a method for this - sortedByAge()

Re: [swift-evolution] InternalString class for easy String manipulation

Nice, thanks :) FWIW, there are at least some ASCII-specific optimizations internally in String (this was a question asked and not answered in the prior thread). On Tue, Aug 16, 2016 at 11:21 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > Here's a little prior d

Re: [swift-evolution] InternalString class for easy String manipulation

Here's a little prior discussion about ASCIIString: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002138.html Jacob On Sun, Aug 14, 2016 at 3:41 PM, Michael Savich via swift-evolution < swift-evolution@swift.org> wrote: > Back in Swift 1.0, subscripting a String was easy

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 8:51 PM, Slava Pestov wrote: > > Here is why we must have that requirement. Consider the following code: > > protocol P { > init() > } > > struct A : P { > init() {} > } > > struct B : P { > init() {} > } > > func makeIt() -> T { > return T() > } > > I can use t

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

> On 16 Aug 2016, at 01:14, David Sweeris via swift-evolution > wrote: > >> On Aug 15, 2016, at 13:55, Michael Ilseman via swift-evolution >> wrote: > >> >> It seems like there’s a potential for confusion here, in that people may see >> “UInt8” and assume there is some kind of typed-ness,

Re: [swift-evolution] InternalString class for easy String manipulation

> On Aug 14, 2016, at 3:41 PM, Michael Savich via swift-evolution > wrote: > > What about having an InternalString subclass that only supports one encoding, > allowing it to be subscripted with Ints? The idea is that an InternalString > is for Strings that are more or less hard coded into the

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 6:51 PM, Slava Pestov wrote: > >> >> On Aug 16, 2016, at 6:40 PM, Charles Srstka > > wrote: >> >>> On Aug 16, 2016, at 8:13 PM, Slava Pestov >> > wrote: >>> >>> -1 — this adds a new syntax with little gain, and p

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 6:40 PM, Charles Srstka wrote: > >> On Aug 16, 2016, at 8:13 PM, Slava Pestov > > wrote: >> >> -1 — this adds a new syntax with little gain, and potentially a lot of >> additional complexity. >> >>> On Aug 16, 2016, at 2:49 PM, Charles Srstka vi

Re: [swift-evolution] Required Callback

Why the callback is special ? The compiler should has a warning for unused parameters of function. I think this is enough. More works should be leaved for a lint tool. James Campbell via swift-evolution 于2016年8月17日 周三06:39写道： > ​I'm not sure about that last question, I guess someone who knows

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

On Tue, Aug 16, 2016 at 7:44 PM, Xiaodi Wu wrote: > On Tue, Aug 16, 2016 at 7:34 PM, Braeden Profile via swift-evolution < > swift-evolution@swift.org> wrote: > >> Okay, I’m actually confused about the current state of things. >> >> Earlier, this was introduced: >> >> // This function is silly, >

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 8:13 PM, Slava Pestov wrote: > > -1 — this adds a new syntax with little gain, and potentially a lot of > additional complexity. > >> On Aug 16, 2016, at 2:49 PM, Charles Srstka via swift-evolution >> wrote: >> >> Unfortunately, when this has come up on the list in the

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 6:05 PM, Charles Srstka via swift-evolution > wrote: > >> On Aug 16, 2016, at 7:48 PM, Xiaodi Wu > > wrote: >> >> On Tue, Aug 16, 2016 at 7:43 PM, Charles Srstka > > wrote: >>> On Aug 16, 2016, at 7:08 PM, Xiaod

Re: [swift-evolution] PITCH: New :== operator for generic constraints

-1 — this adds a new syntax with little gain, and potentially a lot of additional complexity. > On Aug 16, 2016, at 2:49 PM, Charles Srstka via swift-evolution > wrote: > > Unfortunately, when this has come up on the list in the past, it has been > mentioned that there are some cases where an

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 2:49 PM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > Suppose we have a bunch of peppers, and we’d like to make a function to pick > them. We could just take an array, but Swift supports many types of sequence > types beyond a simple array, and it wou

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 7:48 PM, Xiaodi Wu wrote: > > On Tue, Aug 16, 2016 at 7:43 PM, Charles Srstka > wrote: >> On Aug 16, 2016, at 7:08 PM, Xiaodi Wu > > wrote: >> >> On Tue, Aug 16, 2016 at 6:59 PM, Karl >

Re: [swift-evolution] PITCH: New :== operator for generic constraints

On Tue, Aug 16, 2016 at 7:43 PM, Charles Srstka wrote: > On Aug 16, 2016, at 7:08 PM, Xiaodi Wu wrote: > > > On Tue, Aug 16, 2016 at 6:59 PM, Karl wrote: > >> >> On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Aug 16, 2016, at 5:30 PM

Re: [swift-evolution] Swift for bare-metal programming

2016-08-17 3:27 GMT+03:00 Roderick Mann : > > >> There's also the need to be able to name a specific physical (perhaps > virtual) memory address and do bit operations on them. In C/C++, this is > relatively easy. Not sure how one would do this in Swift. > > > > UnsafeBytes, UnsafePointer, UnsafeBuf

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

On Tue, Aug 16, 2016 at 7:34 PM, Braeden Profile via swift-evolution < swift-evolution@swift.org> wrote: > Okay, I’m actually confused about the current state of things. > > Earlier, this was introduced: > > // This function is silly, > // but useful functions may take a similar form > func foo(x:

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 7:08 PM, Xiaodi Wu wrote: > > On Tue, Aug 16, 2016 at 6:59 PM, Karl > wrote: > >> On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Aug 16, 2016, at 5:30 PM, Xiaodi Wu >>

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

Okay, I’m actually confused about the current state of things. Earlier, this was introduced: // This function is silly, // but useful functions may take a similar form func foo(x: Int?) -> Int? { guard let x = x else { return 0 } return x > 12 ? nil : x + 1 } let a: Int? = nil for i in seque

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 6:59 PM, Karl via swift-evolution > wrote: > > I think the point is that existentials not conforming to their protocols is > the underlying reason this doesn’t work already. > > From the previous thread: >> There are a couple of reasons this is the case. IIRC in some cas

Re: [swift-evolution] Swift for bare-metal programming

> On Aug 16, 2016, at 15:27 , Anton Zhilin wrote: > > 2016-08-16 23:07 GMT+03:00 Rick Mann via swift-evolution > : >> But to start, I'd like to be able to target the Beaglebone Black (TI Sitara >> AM335x ARM processor). On the swift-users list we talked about this a bit >> (Subject: "Swift in

Re: [swift-evolution] [Discussion] Sortable Attribute

Perfect. I use the phrase "sort on" often and was thinking of suggesting that, but I was afraid it was just jargon in my line of work. On Tue, Aug 16, 2016 at 19:17 Silvan Mosberger wrote: > I'd be in favor. We'd need another name, since the current closure > predicate is already standardized to

Re: [swift-evolution] [Discussion] Sortable Attribute

> I'd be in favor. We'd need another name, since the current closure predicate > is already standardized to `by:`. Haskell uses "on" for sorting with a mapping. There are both sortOn :: Ord b => (a -> b) -> [a] -> [a] and sortBy :: (a -> a -> Ordering) -> [a] -> [a] in Haskell.___

Re: [swift-evolution] PITCH: New :== operator for generic constraints

On Tue, Aug 16, 2016 at 6:59 PM, Karl wrote: > > On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution < > swift-evolution@swift.org> wrote: > > On Aug 16, 2016, at 5:30 PM, Xiaodi Wu wrote: > > > On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution < > swift-evolution@swif

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution > wrote: > >> On Aug 16, 2016, at 5:30 PM, Xiaodi Wu > > wrote: >> >> On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> On Aug 16, 2016

Re: [swift-evolution] [Discussion] Sortable Attribute

2016-08-17 1:45 GMT+03:00 Xiaodi Wu : > On Tue, Aug 16, 2016 at 5:35 PM, Anton Zhilin > wrote: > >> What we need here is sort_by from Ruby. How about adding these >> overloads? >> >> func sort(by: (T) -> U) >> func sorted(by: (T) -> U) -> [T] >> > > I'd be in favor. We'd need another name, sinc

Re: [swift-evolution] [Discussion] Sortable Attribute

On Tue, Aug 16, 2016 at 5:35 PM, Anton Zhilin wrote: > What we need here is sort_by from Ruby. How about adding these overloads? > > func sort(by: (T) -> U) > func sorted(by: (T) -> U) -> [T] > I'd be in favor. We'd need another name, since the current closure predicate is already standardized

Re: [swift-evolution] Required Callback

​I'm not sure about that last question, I guess someone who knows more about it than me could answer.​ *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 16 A

Re: [swift-evolution] Required Callback

@noescape is a hint that the callback will only be called once and allows compiler to optimise, we may or may not be able to combine @required functionality into that but it looks like it was rejected for now. @required is a compiler hint / sanity check to enforce that the callback is actually cal

Re: [swift-evolution] [Discussion] Sortable Attribute

What we need here is sort_by from Ruby. How about adding these overloads? func sort(by: (T) -> U) func sorted(by: (T) -> U) -> [T] ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 5:30 PM, Xiaodi Wu wrote: > > On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> On Aug 16, 2016, at 5:13 PM, David Sweeris > > wrote: >> >> Any proposal that expands the power of g

Re: [swift-evolution] PITCH: New :== operator for generic constraints

On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > On Aug 16, 2016, at 5:13 PM, David Sweeris wrote: > > > Any proposal that expands the power of generic programming gets an almost > automatic +1 from me. > > I can't think of any circumstance

Re: [swift-evolution] Swift for bare-metal programming

2016-08-16 23:07 GMT+03:00 Rick Mann via swift-evolution < swift-evolution@swift.org>: > I'm not sure what effort is already underway to support this, but I'd like > to be able to take advantage of Swift's inherent robustness to develop code > for embedded devices without the benefit of an OS like

Re: [swift-evolution] [Discussion] Sortable Attribute

A core team-driven proposal that didn't get sufficiently refined before the Swift 3 cutoff was to refine Equatable and Comparable. The direction that the core team was going was this: if your class is Comparable, then it defines a total order, and `sort()` and `sorted()` are to be a stable sort bas

Re: [swift-evolution] PITCH: New :== operator for generic constraints

> On Aug 16, 2016, at 5:13 PM, David Sweeris wrote: > > Any proposal that expands the power of generic programming gets an almost > automatic +1 from me. > > I can't think of any circumstances in which I wouldn't want to use ":==" > instead of ":". Are there any downsides to expanding ":" to m

Re: [swift-evolution] Required Callback

What are the differences between and ? application(_:handleEventsForBackgroundURLSession:completionHandler:) has an @escaping `completionHandler`, so can @r

Re: [swift-evolution] PITCH: New :== operator for generic constraints

Any proposal that expands the power of generic programming gets an almost automatic +1 from me. I can't think of any circumstances in which I wouldn't want to use ":==" instead of ":". Are there any downsides to expanding ":" to mean what ":==" does? Incidentally, I kinda thought things either

Re: [swift-evolution] PITCH: New :== operator for generic constraints

It's weird to me that protocol-typed objects aren't seen as conforming to that protocol. I would intuitively expect this function to work for both a sequence of Pepper types and other types that conform to Pepper: func pick(peppers: PepperType) where PepperType.Iterator.Element: Pepper { // pic

[swift-evolution] PITCH: New :== operator for generic constraints

MOTIVATION: Suppose we have a bunch of peppers, and we’d like to make a function to pick them. We could just take an array, but Swift supports many types of sequence types beyond a simple array, and it would be nice to support those as well, particularly since we have this one client who stores

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Hi Justin, First of all I like your idea! Second, I understand the concerns of Xiaodi but I don't think the short-circuit problem is that big. Functions which have a non Void return type mostly have no side effects (at least in my code base). Furthermore the less explicit control flow (only one

[swift-evolution] [Discussion] Sortable Attribute

Hi there, I'm not really sure whether this is appropriate, considering that Swift 4 should be basically focusing purely on ABI compatibility and a few other issues mentioned by Chris, but I've been thinking about this for some time and would make a lot of lives easier, so it could be part of 3.

Re: [swift-evolution] Amendment to SE-0112: Default values for errorDomain and errorCode

+1 Sent from my iPhone > On Aug 5, 2016, at 18:32, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > SE-0112 includes the CustomNSError protocol, which includes the properties > errorDomain, errorCode, and errorUserInfo. These properties can be used to > tell Swift how to conv

Re: [swift-evolution] Required Callback

Proposed ! https://github.com/apple/swift-evolution/pull/502 *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 16 August 2016 at 20:44, James Campbell wrote

[swift-evolution] Swift for bare-metal programming

I'm not sure what effort is already underway to support this, but I'd like to be able to take advantage of Swift's inherent robustness to develop code for embedded devices without the benefit of an OS like Linux. I see at least two classes of such development: small and large embedded processors

Re: [swift-evolution] Required Callback

That sounds fair, the closure that function returns could trigger a runtime warning when it detects the closure has be deallocated without being triggered (or even mutliple times but ofc not the focus for this proposal) *___* *James⎥Lead Hustler* *ja...@supmenow

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

On Tue, Aug 16, 2016 at 12:14 PM, Justin Jia wrote: > I was trying to argue with reason. You kept stating your *opinion*. You > still didn't explain *why*. For example, why "if statements can and > function calls can't" and why "this severely violates user expectations"? > These were not meant a

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> On 16 Aug 2016, at 20:24, Justin Jia via swift-evolution > wrote: > > Thank you for the sharing how you solve this problem! It seems like the best > workaround so far. > > I wish $0 can be replaced by the actual name. (Maybe tuples?) > > let a = (x: x, y: y) > let result = a.my_map { foo(

Re: [swift-evolution] Required Callback

One alternative that comes to mind: The @escaping stuff came with a helper function, withoutActuallyEscaping, to deal with attribute mismatches. Perhaps we could have the same here, for consistency, something like withActuallyInvoking? On Tue, Aug 16, 2016 at 12:05 Xiaodi Wu wrote: > Well, the c

Re: [swift-evolution] Amendment to SE-0112: Default values for errorDomain and errorCode

> On Aug 5, 2016, at 4:32 PM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > SE-0112 includes the CustomNSError protocol, which includes the properties > errorDomain, errorCode, and errorUserInfo. These properties can be used to > tell Swift how to convert an error to an NSE

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Thank you for the sharing how you solve this problem! It seems like the best workaround so far. I wish $0 can be replaced by the actual name. (Maybe tuples?) let a = (x: x, y: y) let result = a.my_map { foo(x: $0.x, y: $0.y } In my_map unwrap all variables inside tuple? I agree that short-cir

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

I was trying to argue with reason. You kept stating your *opinion*. You still didn't explain *why*. For example, why "if statements can and function calls can't" and why "this severely violates user expectations"? I'm always willing to discuss the problem, and I don't mind to reevaluate my idea

Re: [swift-evolution] Required Callback

Well, the callsite @required would be what I call your escape hatch :) Hmm, lemme think on this... On Tue, Aug 16, 2016 at 11:59 James Campbell wrote: > It would though, look :) : > > Backend.run() { requiredCallback in > > NonAnotatedModuled({ > > //We send a anon closure to the module and we

Re: [swift-evolution] Required Callback

It would though, look :) : Backend.run() { requiredCallback in NonAnotatedModuled({ //We send a anon closure to the module and we call the callback with a required specifier to indicate to the compiler it will be called :) @required requiredCallback() }) } This would be the same as this: Bac

Re: [swift-evolution] Required Callback

Wait, doesn't work. Your anonymous closure would then be dinged for not satisfying the requirement. Turtles all the way down. Still need an escape hatch. On Tue, Aug 16, 2016 at 11:54 James Campbell wrote: > I'll write up a draft proposal :) I think we have something nice :) > > *

Re: [swift-evolution] Required Callback

I'll write up a draft proposal :) I think we have something nice :) *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 16 August 2016 at 17:54, Xiaodi Wu wro

Re: [swift-evolution] Required Callback

Nicer still! On Tue, Aug 16, 2016 at 11:53 James Campbell wrote: > I guess that would make sense and you could wrap the callback up in a > anon-closure if the module hadn't adpated the @required property so you get > both compatibility, safety and clarity. > > *___

Re: [swift-evolution] Required Callback

I guess that would make sense and you could wrap the callback up in a anon-closure if the module hadn't adpated the @required property so you get both compatibility, safety and clarity. *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com

Re: [swift-evolution] Required Callback

Nice! Still need an escape hatch for when that other function isn't annotated though, for those situations when you *know* it's always going to be called and that you should never call it twice. On Tue, Aug 16, 2016 at 11:50 Haravikk wrote: > > On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolut

Re: [swift-evolution] Required Callback

> On 16 Aug 2016, at 15:49, Xiaodi Wu via swift-evolution > wrote: > > I can see the use case, but it'd be annoying (or, impossible) to work around > if I intend to call `end` by passing it to a helper function in another > (let's say, precompiled) module. There's no way for the compiler to i

Re: [swift-evolution] Required Callback

I think that tidies it up a lot, that would make it stick out a lot for me especially when dealing with iOS's app delegate callbacks. *___* *James⎥Lead Hustler* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square*

[swift-evolution] [Accepted] SE-0137: Avoiding Lock-In to Legacy Protocol Designs

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0137-avoiding-lock-in.md The review of "SE-0137: Avoiding Lock-In to Legacy Protocol Designs" ran from August 10th through the 14th. The proposal has been *accepted*. Community feedback to this proposal was light but

Re: [swift-evolution] Required Callback

I wonder if we can be a little more elegant: - no need for an optional message: if the compiler is going to force you the implementor to call something, it really doesn't matter why--you just call it; any additional explanation can be given in doc comments - at the implementation site, you the im

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

I use map/flatMap when I have an optional parameter to a method: let result = x.map { foo.bar(x: $0) } My only grief is that it doesn't work too well when you have many optionals that you want to unwrap and use as parameters. I tend to agree that short-circuiting call expressions from their arg

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

We don't design the language in a vacuum. If statements can short-circuit and function calls can't. You are proposing a function call that can short-circuit. This severely violates user expectations. On Tue, Aug 16, 2016 at 10:03 Justin Jia wrote: > I will reply both of your email in this simple

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

I will reply both of your email in this simple email. > On Aug 16, 2016, at 10:26 PM, Xiaodi Wu wrote: > > Top-replying because Google is forcing me to: > > If you want to print an error for all early exits, declare a variable to keep > track of exit status such as `var isEarlyExit = false`,

Re: [swift-evolution] Required Callback

I think as long as the end callback is referenced in some way that would still be better than what we have now, if you pass it into your own code but then continue on to not call it then I think it would be fair for the compiler to let you shoot yourself in the foot in that case. Calling end more

Re: [swift-evolution] Required Callback

I can see the use case, but it'd be annoying (or, impossible) to work around if I intend to call `end` by passing it to a helper function in another (let's say, precompiled) module. There's no way for the compiler to inspect that `end` is always called by that other module, and if calling `end` twi

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

I have already explained why your proposal is not at all like optional chaining. Your proposal hides complicated control flow changes, but optional chaining does not. It does not do you any good to argue that "most people won't nest functions inside functions". First of all, that's an unbelievable

Re: [swift-evolution] InternalString class for easy String manipulation

The utf16 property can already be subscripted with an Int, just as you desire, if you import Foundation. (See the code for corelibs-foundation for an intriguing discussion of why you must import Foundation at the moment.) On Tue, Aug 16, 2016 at 02:00 Michael Savich wrote: > What about adding a

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> On Aug 16, 2016, at 9:52 PM, Xiaodi Wu wrote: > > That is indeed idiomatic Swift. You will find it frequently in code written > in the language, and in other discussions it has been said (and at one point, > directly in reply to me) that it is the preferred way of expressing this > check. >

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Top-replying because Google is forcing me to: If you want to print an error for all early exits, declare a variable to keep track of exit status such as `var isEarlyExit = false`, then use a defer block that prints `error` only after checking `isEarlyExit` (or, you know, design your code so that `

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

That is indeed idiomatic Swift. You will find it frequently in code written in the language, and in other discussions it has been said (and at one point, directly in reply to me) that it is the preferred way of expressing this check. This spelling is superior to your proposal for a reason you've a

[swift-evolution] Required Callback

It would be handy if a callback could be marked as required with an optional descriptive message i.e class BackgroundTask { func run(end: @required("You must call end otherwise iOS will penalise your app for being a bad citizen") () -> Void) } That was the developer can comunicate the bad things

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Sounds like a good alternative. This is something programmer can implement by themselves! IMO ??? is too magical. Or even Ruby Style syntax (which came up before). foo(x, y) where x?, y? Justin > On Aug 16, 2016, at 7:14 PM, David Sweeris wrote: > > What about something like these? > func

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

What about something like these? func optionally (a: T?, f: (T)->U) -> U? { guard a = a else {return nil} return f(a) } func optionally (a1: T?, a2: U?, f: (T, U)->V) -> V? { guard a1 = a1, a2 = a2 else {return nil} return f(a1, a2) } //etc Is this the thread in which someone pos

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> On 15 Aug 2016, at 20:39, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Aug 15, 2016 at 2:29 PM, Tim Vermeulen > wrote: > >> On 15 Aug 2016, at 21:27, Xiaodi Wu > > wrote: >> >> On Mon, Aug 15, 2016 at 1:57 PM, Haravikk via swift-e

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

It's true, empty sequences aren't inherently unsafe but an oversight of the nil case can lead to unexpected empty sequences which then lead to bugs. Eg.: let number = Int(string) for i in sequence(first: number, next: { $0 * 2 - 1 }).prefix(10) { print(i) } If the string cannot be converted