Re: [swift-evolution] [Proposal] Type Narrowing

> On 09 Nov 2016, at 07:51, David Hart via swift-evolution > wrote: > > >> On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution >> wrote: >> >> This looks like a lot of complexity for very little gain. >> >> Aside from any implementation concerns, this proposal substantiall

Re: [swift-evolution] [Proposal] Type Narrowing

> On 8 Nov 2016, at 12:22, ilya wrote: > > (1) You can define different methods with the same name on T and Optional > (description is such an example). Then what does this do? > > // someMethod is defined both for T and T? > // var foo: T? > if foo != nil { > foo.someMethod() > } > > I s

Re: [swift-evolution] [Proposal] Type Narrowing

> What do you imagine being inside .complicatedStuff()? It shouldn't be possible for it to change foo to nil, as even if .complicatedStuff() reassigned this, it would be doing so as type T. Why do you think so? All objects can be changed in any method. Let's rename foo to pet and complicatedStuff

Re: [swift-evolution] [Proposal] Type Narrowing

> On 9 Nov 2016, at 10:00, ilya wrote: > > > What do you imagine being inside .complicatedStuff()? It shouldn't be > > possible for it to change foo to nil, as even if .complicatedStuff() > > reassigned this, it would be doing so as type T. > > Why do you think so? All objects can be changed

Re: [swift-evolution] [Proposal] Type Narrowing

> On 09 Nov 2016, at 10:51, Haravikk via swift-evolution > wrote: > > >> On 8 Nov 2016, at 12:22, ilya wrote: >> >> (1) You can define different methods with the same name on T and Optional >> (description is such an example). Then what does this do? >> >> // someMethod is defined both for

Re: [swift-evolution] [Proposal] Type Narrowing

> On 9 Nov 2016, at 12:19, Rien wrote: >> On 9 Nov 2016, at 06:51, David Hart wrote: >>> On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution >>> wrote: >>> >>> This looks like a lot of complexity for very little gain. >>> >>> Aside from any implementation concerns, this prop

Re: [swift-evolution] [Proposal] Type Narrowing

> The difference here is that unlike shadowing (if let foo = foo), if foo were mutable then it could still be mutated directly, no need to do it with force unwrapping. FWIW, there is no need for force unwrapping in any case. var bar:Foo? = nil if let real_foo = foo { bar = real_foo } if var bar

Re: [swift-evolution] [Proposal] Type Narrowing

I get narrowing, and have admittedly often wished for it myself. Hence I have kept out of this discussion. But the argument for cognitive overload is imo convincing. When we create examples, there is almost no (or even negative) cognitive load associated with narrowing. However when you get a pi

Re: [swift-evolution] [Pitch] Nil struct

-1 Personally, I don’t like writing “nil” at all. In my understanding of Swift, “nil” is simply a C-like shorthand for "Optional.none”. If the compiler can’t infer T (such as “let a = nil”), it should fall-back to Optional.none; I’m very surprised that this isn’t the case currently. There is a

Re: [swift-evolution] [Pitch] Nil struct

> On 9 Nov 2016, at 16:55, Karl wrote: > > If the compiler can’t infer T (such as “let a = nil”), it should fall-back to > Optional.none; I’m very surprised that this isn’t the case currently. > Oh, it is the case currently: let a = nil error: repl.swift:1:9: error: 'nil' requires a contextu

Re: [swift-evolution] [Proposal] Enums with stored properties

I think your second point is quite interesting! We should consider expanding this so that we can get any associated value: // from the Swift book enum Barcode { case upc(Int, Int, Int, Int) case qrCode(String) } let code = Barcode.upc(9,2,3,4) if let upcCode = code.upc { // upcCode:

[swift-evolution] Some concerns on custom operators

1. Upon implementation of SE-0077 in Swift 3, some libraries started to drop operators entirely: link #1 , link #2 . - Declarations of the same custom operator with different preced

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

> On Nov 4, 2016, at 5:28 AM, Max Desiatov via swift-evolution > wrote: > > Hi all, > >> On 31 Oct 2016, at 21:23, Anders Bertelrud via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> * What is your evaluation of the proposal? > > -1 > >> * Is the problem being

Re: [swift-evolution] [Proposal] Type Narrowing

So I'm trying to re-write the proposal with the use of a keyword for unwrapping in mind, to keep it simpler for myself I've done this as two separate proposals for the time being, one for simpler unwrapping of optionals, and one for type-narrowing of polymorphic types: https://github.com/Haravi

Re: [swift-evolution] Some concerns on custom operators

> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution > wrote: > > Upon implementation of SE-0077 in Swift 3, some libraries started to drop > operators entirely: link #1 > , link #2 >

[swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

Although out of scope for phase 1, something that keeps cropping up in a variety of Linux/Darwin Swift scripts is the conditional inclusion of Darwin or GlibC per platform. The last point was an observation that creating a 'nice' wrapper for LibC or a cleaned up POSIX API is a non-goal: https:/

Re: [swift-evolution] Some concerns on custom operators

> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution > wrote: > • Upon implementation of SE-0077 in Swift 3, some libraries started to > drop operators entirely: link #1, link #2. > • Declarations of the same custom operator with different > precedence groups creat

Re: [swift-evolution] Some concerns on custom operators

2016-11-09 21:56 GMT+03:00 Joe Groff : > > Do you know if bugs have been filed about these issues? IIRC, SE-0077 > specified that precedence groups should act like normal named declarations > and be scopable. The fact that they aren't sounds like a bug to be fixed. > I don't know of any. At one st

Re: [swift-evolution] Some concerns on custom operators

2016-11-09 22:20 GMT+03:00 John McCall : > > On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution < > swift-evolution@swift.org> wrote: > > • Upon implementation of SE-0077 in Swift 3, some libraries > started to drop operators entirely: link #1, link #2. > > • Declarat

Re: [swift-evolution] Some concerns on custom operators

on Wed Nov 09 2016, John McCall wrote: >> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution >> wrote: >> • Upon implementation of SE-0077 in Swift 3, some libraries started to drop >> operators entirely: > link #1, link #2. >> • Declarations of the same custom operator with differe

Re: [swift-evolution] Some concerns on custom operators

> On Nov 9, 2016, at 1:24 PM, Dave Abrahams via swift-evolution > wrote: > on Wed Nov 09 2016, John McCall > wrote: > >>> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution >>> wrote: >>> • Upon implementation of SE-0077 in Swift 3, some libraries s

Re: [swift-evolution] Some concerns on custom operators

on Wed Nov 09 2016, John McCall wrote: >> On Nov 9, 2016, at 1:24 PM, Dave Abrahams via swift-evolution >> wrote: >> on Wed Nov 09 2016, John McCall > > > wrote: >> On Nov 9, 2016, at 9:25 AM, Anton Zhilin via swift-evolution wrote: • Upon im

[swift-evolution] [Review extended] SE-0143: Conditional Conformances

During the first round of review for SE-0143, there was concern about the clarity of the proposal as written, since the discussion fixated on a number of ancillary issues not intended to be core to the proposal. Doug has revised the proposal for another round of feedback, so the review period fo

[swift-evolution] gyb template for ZipSequence

This stack overflow question asks about using zip with more than 3 sequences. I referred the OP to the generics manifesto , which describes the (current) lack of

Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

> On Nov 9, 2016, at 10:58 AM, Alex Blewitt via swift-evolution > wrote: > > Although out of scope for phase 1, something that keeps cropping up in a > variety of Linux/Darwin Swift scripts is the conditional inclusion of Darwin > or GlibC per platform. The last point was an observation that

Re: [swift-evolution] [Out of scope] Discussion on general Darwin/GlibC module

on Wed Nov 09 2016, Matt Wright wrote: >> On Nov 9, 2016, at 10:58 AM, Alex Blewitt via swift-evolution >> wrote: >> >> Although out of scope for phase 1, something that keeps cropping up >> in a variety of Linux/Darwin Swift scripts is the conditional >> inclusion of Darwin or GlibC per plat

Re: [swift-evolution] gyb template for ZipSequence

on Wed Nov 09 2016, Alexander Momchilov wrote: > This stack overflow question > asks about using zip > with more than 3 sequences. I referred the OP to the generics > manifesto >