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

I see a pattern of myself writing code like this now: ``` func foo(x: Int?) -> Int? { guard x = x else { return nil } /* normal function */ } ``` This is even worse than the x? syntax. But sometimes I have no other choice. Most of my functions are without side effects and… I don’t want t

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

> On Aug 16, 2016, at 1:51 AM, Xiaodi Wu wrote: > > On Mon, Aug 15, 2016 at 12:31 PM, Justin Jia > wrote: > > Since you mentioned do and defer: > > ``` > func foo(wantsToBreak: Bool) { > out: do { > defer { print("Hello, world!") } >

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

The major problem with this approach is that visual glyphs themselves have one level of variable-length encoding, and they sit on top of another variable-length encoding used to represent the Unicode characters (Swift-native Strings are currently encoded as UTF-8). For instance, the visual glyph

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

On Mon, Aug 15, 2016 at 8:43 PM, Tim Vermeulen wrote: > Point taken, in theory it is possible that someone’s program would change > unexpectedly if we change the function’s signature. But wouldn’t you agree > that this was a very contrived example? I can’t think of a lot more than > converting it

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

Point taken, in theory it is possible that someone’s program would change unexpectedly if we change the function’s signature. But wouldn’t you agree that this was a very contrived example? I can’t think of a lot more than converting it to a string that works on both optionals and non-optionals.

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

On Mon, Aug 15, 2016 at 7:23 PM, Tim Vermeulen wrote: > > On 16 Aug 2016, at 02:11, Xiaodi Wu wrote: > > On Mon, Aug 15, 2016 at 7:03 PM, Tim Vermeulen wrote: > >> If I'm not mistaken, the type of T can be inferred from the `next` >> closure here. $0 is an optional, so you end up with a sequenc

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

> On 16 Aug 2016, at 02:11, Xiaodi Wu wrote: > > On Mon, Aug 15, 2016 at 7:03 PM, Tim Vermeulen > wrote: > If I'm not mistaken, the type of T can be inferred from the `next` closure > here. $0 is an optional, so you end up with a sequence of optionals. > > Currently,

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

On Mon, Aug 15, 2016 at 7:03 PM, Tim Vermeulen wrote: > If I'm not mistaken, the type of T can be inferred from the `next` closure > here. $0 is an optional, so you end up with a sequence of optionals. > Currently, yes. But if we have both public func sequence(first: T, next: @escaping (T) -> T

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

If I'm not mistaken, the type of T can be inferred from the `next` closure here. $0 is an optional, so you end up with a sequence of optionals. > On 16 Aug 2016, at 00:51, Xiaodi Wu wrote: > > Given: > > let foo: T? = something() > let bar = sequence(first: foo, next: { $0?.frobnicate() }) >

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

> 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, even though the whole > point is that this is untyped. Adjusting the header comment

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

> On Aug 15, 2016, at 17:51, David Hart via swift-evolution > wrote: > > I prefer the much simpler and natural: > > let value = x.map { foo.bar(x: $0) } > > Is it me or has everybody been avoiding the map solution for some reason. > It's the most elegant way to do such operations IMHO. It do

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

I prefer the much simpler and natural: let value = x.map { foo.bar(x: $0) } Is it me or has everybody been avoiding the map solution for some reason. It's the most elegant way to do such operations IMHO. > On 15 Aug 2016, at 22:05, Charles Srstka via swift-evolution > wrote: > >> On Aug 15,

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

Given: let foo: T? = something() let bar = sequence(first: foo, next: { $0?.frobnicate() }) If first could be of type `T` or `T?`, is bar of type `UnfoldSequence` or `UnfoldSequence`? On Mon, Aug 15, 2016 at 17:15 Tim Vermeulen via swift-evolution < swift-evolution@swift.org> wrote: > I doubt th

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

To what benefit? On Mon, Aug 15, 2016 at 16:23 Charles Srstka wrote: > On Aug 15, 2016, at 3:08 PM, Xiaodi Wu wrote: > > > On Mon, Aug 15, 2016 at 3:05 PM, Charles Srstka > wrote: > >> On Aug 15, 2016, at 2:27 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >>

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

I doubt that’s it, in no way is an an empty sequence inherently unsafe. The entire standard library is built with empty sequences in mind. I’m more inclined to think it’s an oversight. > On 15 Aug 2016, at 23:15, Maximilian Hünenberger > wrote: > > Ok, I see. However this could be a potential

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

> On Aug 15, 2016, at 3:08 PM, Xiaodi Wu wrote: > > On Mon, Aug 15, 2016 at 3:05 PM, Charles Srstka > wrote: >> On Aug 15, 2016, at 2:27 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> `let value = (x == nil) ? nil : foo.bar

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

Ok, I see. However this could be a potential source of bugs/performance issues where you don't consider the nil case and you do some unnecessary work. By prohibiting to pass nil you have to manually unwrap and you immediately see the "optionality". > Am 15.08.2016 um 22:36 schrieb Tim Vermeulen

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

> On 15 Aug 2016, at 22:08, Xiaodi Wu wrote: > > > > On Mon, Aug 15, 2016 at 3:05 PM, Charles Srstka > wrote: >> On Aug 15, 2016, at 2:27 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> `let value = (x == nil) ? nil : foo

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

Probably I didn't understand your proposal. What do you want to change exactly? I thought: public func sequence(first: T, next: @escaping (T) -> T?) -> UnfoldFirstSequence { ... } To: public func sequence(first: T?, next: @escaping (T) -> T?) -> UnfoldFirstSequence { ... } > Am 15.08.2016 um 2

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

Hi Tim, If you pass "nil" to "first" isn't this an empty sequence? So it would be redundant. Best regards Maximilian > Am 15.08.2016 um 01:27 schrieb Tim Vermeulen via swift-evolution > : > > sequence(first:next:) takes a non-optional first argument. Is there a reason > for that? sequence(st

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

On Mon, Aug 15, 2016 at 3:05 PM, Charles Srstka wrote: > On Aug 15, 2016, at 2:27 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > `let value = (x == nil) ? nil : foo.bar(x: x)` isn't so bad, is it? You > could even write a custom operator to sugar it. > > > It’s dist

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

> On Aug 15, 2016, at 3:05 PM, Charles Srstka wrote: > > let value: Foo? = nil This line should have been just 'let value: Foo?' . (+1 on the proposal to move to a web-based forum that allows editing, if that’s still under consideration.) Charles _

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

> On Aug 15, 2016, at 2:27 PM, Xiaodi Wu via swift-evolution > wrote: > > `let value = (x == nil) ? nil : foo.bar(x: x)` isn't so bad, is it? You could > even write a custom operator to sugar it. It’s distasteful, due to the need to use the force-unwrap operator. In cases like this, I usually

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

Thanks i'll try to clarify in the comments that The memory is read out as UInt8 but the memory is untyped. Andy > On Aug 15, 2016, at 11:55 AM, Michael Ilseman wrote: > > It seems like there’s a potential for confusion here, in that people may see > “UInt8” and assume there is some kind of t

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

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-evolution < > swift-evolution@swift.org> wrote: > >> >> On 15 Aug 2016, at 13:44, Tim Vermeulen wrote: >> >> On 15 Aug 2016, at 08:02, Jus

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

> On 15 Aug 2016, at 21:27, Xiaodi Wu wrote: > > On Mon, Aug 15, 2016 at 1:57 PM, Haravikk via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On 15 Aug 2016, at 13:44, Tim Vermeulen > > wrote: >> On 15 Aug 2016, at 08:02, Justin Jia via s

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

On Mon, Aug 15, 2016 at 1:57 PM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 15 Aug 2016, at 13:44, Tim Vermeulen wrote: > > On 15 Aug 2016, at 08:02, Justin Jia via swift-evolution evolut...@swift.org(mailto:swift-evolution@swift.org > )>wrote: > Hi! > > I don’t know

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

> On 15 Aug 2016, at 13:44, Tim Vermeulen wrote: > >>> On 15 Aug 2016, at 08:02, Justin Jia via >>> swift-evolutionmailto:swift-evolution@swift.org)>wrote: >>> Hi! >>> >>> I don’t know if this has came up before. I tried to search though the >>> mailing list but didn’t find any related thread

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

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, even though the whole point is that this is untyped. Adjusting the header comments slightly might help: /// A non-owning view of raw memory as a collection of bytes

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

On Mon, Aug 15, 2016 at 1:07 PM, Michael Savich wrote: > At the risk of treading on sacred ground, does Swift need arbitrary > Unicode in identifiers? The Swift guidebook uses emojis as variable names > as an example of the benefits of this which is… not convincing... > The ship has sailed on th

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

> On Aug 14, 2016, at 4:41 PM, Michael Savich via swift-evolution > wrote: > > Back in Swift 1.0, subscripting a String was easy, you could just use > subscripting in a very Python like way. But now, things are a bit more > complicated. I recognize why we need syntax like str.startIndex.advan

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

I just want to mention that the standard library team (or, more specifically, Dave and Dmitri) is planning a rewrite of Swift's String subsystem, in part to make it easier to work with strings in the "common case". We may want to get their input, or wait until they've prepared a proposal. Best, Au

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

Swift supports arbitrary Unicode for identifier names, so Unicode would have to be supported even for debugging strings. On Mon, Aug 15, 2016 at 12:54 Michael Savich wrote: > Well, the thing I've been thinking is that InternalString doesn't have to > be just for learning. There is value in disti

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

I agree with both points of view. I think we need to bring back subscripting on strings which does the thing people would most commonly expect. I would say that the subscripts indexes should correspond to a visual glyph. This seems reasonable to me for most character sets like Roman, Cyrillic,

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

On Mon, Aug 15, 2016 at 12:31 PM, Justin Jia wrote: > > Since you mentioned do and defer: > > ``` > func foo(wantsToBreak: Bool) { > out: do { > defer { print("Hello, world!") } > guard wantsToBreak else { break out } > } > print("End of function.") > } > > foo(wantsTo

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

On Sun, Aug 14, 2016 at 5:41 PM, Michael Savich via swift-evolution < swift-evolution@swift.org> wrote: > Back in Swift 1.0, subscripting a String was easy, you could just use > subscripting in a very Python like way. But now, things are a bit more > complicated. I recognize why we need syntax lik

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

Since you mentioned do and defer:```func foo(wantsToBreak: Bool) {    out: do {        defer { print("Hello, world!") }        guard wantsToBreak else { break out }    }    print("End of function.")}foo(wantsToBreak: true) // Output: Hello, world!\nEnd of function.foo(wantsToBreak: false) // Output

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

On Mon, Aug 15, 2016 at 12:07 PM, Xiaodi Wu wrote: > On Mon, Aug 15, 2016 at 11:43 AM, Justin Jia com> wrote: > >> I believe the core team has considered 99% of the ideas in the mailing >> list in the past, but it doesn’t mean we can’t discuss it, right? >> > > No, it certainly doesn't! I'm sayi

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

On Mon, Aug 15, 2016 at 11:43 AM, Justin Jia wrote: > I believe the core team has considered 99% of the ideas in the mailing > list in the past, but it doesn’t mean we can’t discuss it, right? > No, it certainly doesn't! I'm saying that you haven't come up with a solution to a known problem with

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

I agree that being explicit is nice and I also like to use `guard`. But according to my observation, usually it is easier to make mistakes if we choose to use `guard`. Let me give you a fake real world example. With `guard`, you need to be really careful when you want to add new expression (pe

[swift-evolution] InternalString class for easy String manipulation

Back in Swift 1.0, subscripting a String was easy, you could just use subscripting in a very Python like way. But now, things are a bit more complicated. I recognize why we need syntax like str.startIndex.advancedBy(x) but it has its downsides. Namely, it makes things hard on beginners. If one o

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

I believe the core team has considered 99% of the ideas in the mailing list in the past, but it doesn’t mean we can’t discuss it, right? Assuming we have the following declaration: ``` func foo(a: Int, b: Int?, c: Int, d: Int?) -> Int ``` For this: ``` let z = foo(a: f1(), b: f2()?, c: f3(), d

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

> On 15 Aug 2016, at 15:29, Justin Jia via swift-evolution > wrote: > > IMO `if x? { }` is not a lot shorter than `if let x = x`. > > The problem with `if let` is, you need to explicit specify { } and call the > function inside it. It is good for being explicit, but sometimes you ended up >

Re: [swift-evolution] [Proposal] Sealed classes by default

Yeah I am fairly sure at this point in time "open" is purely about a statement of API contract (defaulted such to favor being explicit) which IMHO is a very good tool to have in the toolbox for module/framework developers. If it proves out to work well then I believe compiler optimizations could st

Re: [swift-evolution] [Proposal] Sealed classes by default

Yeah I know - that's why I said it would only work if we are okay with saying non-open != final, as a long-term decision. So the compiler won't devirtualize those calls. As I understand it, that is how it works today - calls to non-open, non-final classes are still dynamically dispa

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

What do you mean, limited to variables? What about a computed property? You will have the same problem. I'm not sure where you want to go with this, given that the core team has considered the same idea in the past and found these issues to have no good solution. On Mon, Aug 15, 2016 at 04:56 Jus

Re: [swift-evolution] [Pre-Proposal-Discussion] Union Type - Swift 4

I considered the enum approach but it is very tedious to use "space.add(.point(point))" which also doesn't add any clarity. The other approach where we add the properties of a Point as associated values also has a major drawback: // you cannot create a point without "erasing" it's type let point

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

IMO `if x? { }` is not a lot shorter than `if let x = x`. The problem with `if let` is, you need to explicit specify { } and call the function inside it. It is good for being explicit, but sometimes you ended up with something like this: ``` /* code 1 */ if let x = x, let y = y { / * code 2

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

> > On 15 Aug 2016, at 08:02, Justin Jia via > > swift-evolutionmailto:swift-evolution@swift.org)>wrote: > > Hi! > > > > I don’t know if this has came up before. I tried to search though the > > mailing list but didn’t find any related threads. > > > > This is purely a syntactic thing (which I

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

> On 15 Aug 2016, at 08:02, Justin Jia via swift-evolution > wrote: > > Hi! > > I don’t know if this has came up before. I tried to search though the mailing > list but didn’t find any related threads. > > This is purely a syntactic thing (which I know it’s the lowest priority for > Swift 4

Re: [swift-evolution] [Proposal] Sealed classes by default

Well, I walked into that one :( Sorry to trawl all that up on a Sunday. I get it now. “open” is the new “public”, “public, the new “final” at least as far as classes outside the module are concerned. John > On 15 Aug 2016, at 10:51, Tino Heth <2...@gmx.de> wrote: > > >> Am 14.08.2016 um 14:59

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

IMO I don't this bar should be evaluated unless we decide if let can accept non-optional values. Actually, what if we allow if let to accept non-optional values? I agree this is confusing at the beginning. But people who are not familiar with the detail design can avoid this situation easily.

Re: [swift-evolution] [Proposal] Sealed classes by default

> Am 14.08.2016 um 14:59 schrieb Jean-Denis Muys via swift-evolution > : > > This decision is bad, not because it makes the default for classes to be > unsubclassable Seems that the prediction of the grief caused by SE-0117 in the long run was right ;-) — but be careful, the title doesn't ref

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

> Am 15.08.2016 um 09:02 schrieb Justin Jia via swift-evolution > : > > foo.bar(x: x?) Yes, those guards and ifs can be tedious, but it is clear what they are doing, and there is no doubt what code will be evaluated and what will be skipped. If Swift had syntactic sugar that acts like optional

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

On Mon, Aug 15, 2016 at 3:55 AM, Xiaodi Wu wrote: > On Mon, Aug 15, 2016 at 3:25 AM, Justin Jia via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Aug 15, 2016, at 4:09 PM, Charlie Monroe >> wrote: >> >> The example above was to better demonstrate the problem with *when* to >>

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

On Mon, Aug 15, 2016 at 3:25 AM, Justin Jia via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 15, 2016, at 4:09 PM, Charlie Monroe > wrote: > > The example above was to better demonstrate the problem with *when* to > evaluate the latter argument. Why should both arguments be eval

Re: [swift-evolution] [Proposal] Sealed classes by default

This is a detail of implementation and doesn't have to be. You might even imagine the compiler emitting two versions of the code, one assuming the class will not be subclassed, the other not assuming that, and a smart linker linking the right version depending on the case. So for me, in the lo

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

> On Aug 15, 2016, at 4:09 PM, Charlie Monroe wrote: > > The example above was to better demonstrate the problem with *when* to > evaluate the latter argument. Why should both arguments be evaluated *before* > the if statement? If both calls return Optionals, > > if let x = bar(42), y = baz(

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

Thanks for pointing this out! But I think `foo?.bar(baz(42))` should be equivalent to: ``` if let foo = foo { let x = baz(42) foo.bar(x) } ``` IMHO, this is consistent with my example. Instead of worrying about "short-circuit", we can just treat ? as the syntax sugar of if let? > On Au

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

> Le 15 août 2016 à 10:01, Justin Jia via swift-evolution > a écrit : > > >> On Aug 15, 2016, at 3:53 PM, Charlie Monroe > > wrote: >> >>> >>> On Aug 15, 2016, at 9:46 AM, Justin Jia via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

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

> On Aug 15, 2016, at 3:53 PM, Charlie Monroe wrote: > >> >> On Aug 15, 2016, at 9:46 AM, Justin Jia via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I think the `?` will make the return an optional. So your example should add >> another ? at the end. >> >> ``` >> prin

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

> On Aug 15, 2016, at 9:46 AM, Justin Jia via swift-evolution > wrote: > > I think the `?` will make the return an optional. So your example should add > another ? at the end. > > ``` > print(foo(bar(42)?, baz(42)?)?) This reads terribly, IMHO. > ``` > > The above example should be equival

Re: [swift-evolution] [Proposal] Sealed classes by default

> Le 14 août 2016 à 20:43, Karl via swift-evolution > a écrit : > > >> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution >> wrote: >> >> Hi folks, >> >> I see from building the latest Swift-3.0 branch that I’m a little behind the >> times and this proposal has been accepted :(

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

I think the `?` will make the return an optional. So your example should add another ? at the end. ``` print(foo(bar(42)?, baz(42)?)?) ``` The above example should be equivalent to: ``` let x = bar(42) // X is optional let y = baz(42) // Y is optional let z = foo(x?, y?) // Z should be optiona

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

Hi Justin, IIRC, there were several discussions about this, all of them ending up at a dead point. The question was, what would be the behavior of foo(argA: methodA(), argB: methodB()) where methodA returns an optional. If that evaluates to nil, would methodB get evaluated as well? Or should i

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

It has been mentioned before (more than once, perhaps, but not in its own thread I don't think, so good luck finding it). IIRC, one of the problems is that it's unclear what happens if your function takes multiple arguments. Does evaluation proceed from left to right? does it short-circuit? Put con

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

Hi! I don’t know if this has came up before. I tried to search though the mailing list but didn’t find any related threads. This is purely a syntactic thing (which I know it’s the lowest priority for Swift 4), but I think it’s an important one. Let’s say we have a struct with a function: ```