[swift-users] Argument labels

This goes beyond type significance as far as I can tell. Bug report? -- E enum Sample { case foo(Int), bar(label: Int) } let aFoo: Sample = .foo(1) let aBar: Sample = .bar(label: 1) // requires label if case let .foo(value) = aFoo { print(value) } // works if case let .bar(value) = aBar { pri

Re: [swift-users] Implementing a few statistics functions in Swift

…and of course I typoed the minus sign when switching things over. That should be: private(set) var minimum: Number = Number.infinity private(set) var maximum: Number = -Number.infinity Nevin On Mon, Oct 10, 2016 at 4:02 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wr

Re: [swift-users] [swift-evolution] Conditional casting and conditional binding: Wierd edge case or flawed design

> On Oct 10, 2016, at 11:08 AM, Joe Groff wrote: > > >> On Oct 9, 2016, at 1:10 PM, Erica Sadun via swift-evolution >> mailto:swift-evolut...@swift.org>> wrote: >> >> Normally in guard and if condition lists, you look up a value in a >> dictionary and conditionally cast: >> >> if let va

Re: [swift-users] Implementing a few statistics functions in Swift

I rolled my own (rather simple) statistics struct. It had been using Double and Array, but I just went back and made it work generically with FloatingPoint and Sequence. Here’s what it looks like: struct Statistic { private var ssqDev: Number = 0 private(set) var count: Number = 0 priv

Re: [swift-users] ideas to remove NSCoding as requirement in UIView subclasses

You're welcome! Glad to be helpful :) Tadeas On Mon, Oct 10, 2016 at 9:12 PM Lou Zell wrote: > Tadeas - Just what I was looking for. Thank you! > > class BaseView: UIView { > @available(*, unavailable) > required init?(coder aDecoder: NSCoder) { > fatalError("Not implemented!")

Re: [swift-users] ideas to remove NSCoding as requirement in UIView subclasses

Tadeas - Just what I was looking for. Thank you! class BaseView: UIView { @available(*, unavailable) required init?(coder aDecoder: NSCoder) { fatalError("Not implemented!") } } On Mon, Oct 10, 2016 at 11:45 AM, Tadeas Kriz wrote: > Lou, you can create a "class BaseView: U

Re: [swift-users] ideas to remove NSCoding as requirement in UIView subclasses

Lou, you can create a "class BaseView: UIView" which will serve as a default view your views will subclass and inside it, add the init required by NSCoding, make its body `fatalError("Not implemented!")` and add the following attribute on the init: `@available(*, unavailable)`. Then you'll not need

Re: [swift-users] Segfault only when running swift in system-wide directory

Hi Lane, Can you please file a bug on bugs.swift.org? Thanks, Mishal Shah > On Oct 9, 2016, at 11:56 AM, Lane Schwartz via swift-users > wrote: > > Hi, > > I'm on Ubuntu 16, and just downloaded the latest Swift package. When I run > swift from /opt (installed using sudo) as a normal user,

Re: [swift-users] Casting tuples to protocols always fails (and the compiler should know)

> On Oct 10, 2016, at 10:53 AM, Sebastian Hagedorn > wrote: > > “Forever” is pretty long-term ;) > > Since it is currently *not* possible for tuples to conform to protocols, > isn’t it worth a warning (if my assumption that this would be easy to > implement is correct), even if it may be obs

Re: [swift-users] Casting tuples to protocols always fails (and the compiler should know)

“Forever” is pretty long-term ;) Since it is currently *not* possible for tuples to conform to protocols, isn’t it worth a warning (if my assumption that this would be easy to implement is correct), even if it may be obsolete in the future? Thanks for your reply, Sebastian > On 10 Oct 2016, a

Re: [swift-users] Compiler refuses non-escaping closure calls in nested function

> On Oct 9, 2016, at 5:07 PM, Jean-Denis Muys via swift-users > wrote: > > Here is a contrived reduction of my problem > > func mainFunction(closure:(Int) -> Int) -> Int { > > func closureDoubled(_ n: Int) -> Int { > let result = closure(n) > return 2*result > } > >

Re: [swift-users] Implementing a few statistics functions in Swift

Oh yeah, I'd love contributions and feedback! I'm essentially implementing this as I learn things in stats 101 so it's probably woefully inadequate. 😅 -- Harlan > On Oct 10, 2016, at 1:04 PM, Michael Ilseman wrote: > > >> On Oct 8, 2016, at 11:29 AM, Georgios Moschovitis via swift-users >>

Re: [swift-users] Casting tuples to protocols always fails (and the compiler should know)

> On Oct 10, 2016, at 8:20 AM, Sebastian Hagedorn via swift-users > wrote: > > We encountered a very surprising behaviour in one of our apps, and believe > it’s a bug/missing warning in the Swift compilter, but it would be great if > someone could confirm we’re not missing a piece before I fi

Re: [swift-users] Implementing a few statistics functions in Swift

> On Oct 8, 2016, at 11:29 AM, Georgios Moschovitis via swift-users > wrote: > > Hey everyone, > > I would like to implement a few statistics functions in Swift (e.g. variance, > standardDeviation, etc) that are computed over a collection. > > I am aware of this library: > > https://github.

[swift-users] Implementing a few statistics functions in Swift

Hey everyone, I would like to implement a few statistics functions in Swift (e.g. variance, standardDeviation, etc) that are computed over a collection. I am aware of this library: https://github.com/evgenyneu/SigmaSwiftStatistics My problem

Re: [swift-users] Compiler refuses non-escaping closure calls in nested function

So I suppose you feel this case is different from the (unsafe)  implicitly unwrapping of optionals with the “!” operator. Why do you feel the situation is different? > On 10 Oct 2016, at 17:34, Ole Begemann wrote: > >> When I declare my closure as @noescape, (the default), I explicitly tell

Re: [swift-users] Compiler refuses non-escaping closure calls in nested function

When I declare my closure as @noescape, (the default), I explicitly tell the compiler that, despite the fact closing over it *may* allow it to escape, I, the programmer, guarantee that it will not. I would understand a warning, but I don’t understand that the compiler insists on putting out an er

[swift-users] Casting tuples to protocols always fails (and the compiler should know)

We encountered a very surprising behaviour in one of our apps, and believe it’s a bug/missing warning in the Swift compilter, but it would be great if someone could confirm we’re not missing a piece before I file a bug report. This snippet reproduces the issue: protocol MyProto { var title:

Re: [swift-users] Compiler refuses non-escaping closure calls in nested function

Thanks Ole, You are perfectly right regarding the error message. For some reason, I misread it. I am sorry about that. The actual error message, as you point out, makes much more sense! The rest of your explanation makes sense too, except: When I declare my closure as @noescape, (the default),

Re: [swift-users] Compiler refuses non-escaping closure calls in nested function

Thank you, Ole. Your reply teaches me a lot. Zhaoxin On Mon, Oct 10, 2016 at 6:52 PM, Ole Begemann via swift-users < swift-users@swift.org> wrote: > The line "let result = closure(n)" is refused by the compiler with the >> error message "declaration over non closing parameter may allow it to >>

Re: [swift-users] Compiler refuses non-escaping closure calls in nested function

The line "let result = closure(n)" is refused by the compiler with the error message "declaration over non closing parameter may allow it to escape". First off, while I know what an escaping or a non-escaping closure is, I find this error message utterly impossible to understand. To begin with, t

Re: [swift-users] Compiler refuses non-escaping closure calls in nested function: Bug?

> It is just like there were two ways to do the job, you thought it worked in this way, but it chose the other way. Both ways lead to the same result. I think it is because the compiler **flatten** your inner function instead of calculated the result. The variable scope of `closure` is outside th

Re: [swift-users] Compiler refuses non-escaping closure calls in nested function: Bug?

It seems to me you are shooting while blindfolded. > I changed you code `let result = closure(n)` to `let result = closure(1)`. I > thought that should eliminate the error. It didn't. The compiler asked me to > change the whole code as below: Why did you expect changing which argument to send