Re: [swift-users] Range subscript is ambiguous

On May 16, 2016, at 10:09 AM, Joe Groff via swift-users wrote: > >> The oddity is that if I change the assignment to this >> >> var y : [Int] = Array(a[0..> >> then the compiler is happy. >> >> Shouldn’t it be able to do any necessary type inference from the

[swift-users] Member wise initializer doesn't work with default-initialized const properties

Using the default Swift with Xcode 7.3.1. It appears that you cannot use the implicit memberwise initializer with a struct that has “let” properties with default values. This works perfectly: struct CF { let prop: Int } let cf = CF(prop: 1) But give the property a default

Re: [swift-users] super.init() called automatically?

> On May 16, 2016, at 7:09 AM, tuuranton--- via swift-users > wrote: > > Why does the following code compile? > Why does Bar's init(x: Int) automatically call Foo's init()? > Why don't I have to manually call super.init() myself? This is intentional behavior. It kicks

Re: [swift-users] Default value for throwing closure argument of a rethrowing function

> On May 16, 2016, at 2:35 AM, bhargav gurlanka via swift-users > wrote: > > Hi all, > > Could someone please tell me why the following fails? > > func foo(f: () throws -> () = {}) rethrows { > try f() > } > > // Fine > foo({ }) > > // This fails with error: > //

Re: [swift-users] Range subscript is ambiguous

> On May 15, 2016, at 5:31 AM, Neil Faiman via swift-users > wrote: > > This function seems simple enough: > > >func foo(a: [Int], n: Int) { >var x : [Int] = a[0..} > > But it doesn’t compile. > >error: ambiguous subscript with base type

Re: [swift-users] Unexpected Optional unwrapping in generic fn

> On May 15, 2016, at 4:13 PM, Michael Gardner via swift-users > wrote: > > I'm having trouble understanding why the following code is trying to unwrap > an Optional. > > > > class Proxy { > var value:T > init(_ value:T) { >

Re: [swift-users] Initializer inheritance doesn't work with generic class?

This is a known bug. I think Slava's currently working on fixing it. > On May 15, 2016, at 2:41 PM, Neil Faiman via swift-users > wrote: > > Here is another, more blatant example of the failure to inherit initializers > from a generic base class: > >class Concrete {

Re: [swift-users] Conditional generic initializers?

> On May 15, 2016, at 11:55 AM, Neil Faiman via swift-users > wrote: > > Is this a relatively new language change? When I try it with the version of > Swift that comes with Xcode 7.3.1, I get > >error: same-type requirement makes generic parameters 'T1' and 'T2' >

Re: [swift-users] @noescape

Well that was where I was going next, heh. On Mon, May 16, 2016 at 9:41 AM, Jens Alfke wrote: > > On May 16, 2016, at 9:37 AM, Nate Birkholz via swift-users < > swift-users@swift.org> wrote: > > I understand how @noescape works, and some of its benefits, I *think*, but > if

Re: [swift-users] @noescape

> On May 16, 2016, at 9:37 AM, Nate Birkholz via swift-users > wrote: > > I understand how @noescape works, and some of its benefits, I *think*, but if > I am correct, it almost seems like it should be added automatically to my > closure definitions until it becomes

Re: [swift-users] super.init() called automatically?

I did not know of this behavior, but it looks like if the superclasses designated initializer is just a plain init() then it will automatically call super.init() from your subclass. There is no way to avoid not calling your superclasses’s designated initializer and I guess the compiler ensures