Re: [swift-evolution] MemoryLayout for a value

[Dave Abrahams via swift-evolution]

on Fri Aug 05 2016, Boris Wang  wrote:

> Addition:
>
> I think protocol should't has size, or it's size should be zero.
> Because you can't put the 40 bytes data in anywhere.

You certainly can.  If protocols didn't have a size, Array wouldn't be
able to store them.

>
>
> Boris Wang 于2016年8月6日 周六10:35写道：
>
>> codes in swift REPL:
>>
>> protocol P {
>> var x:Int {get}
>> }
>> MemoryLayout.size
>> //r0 : Int = 40
>>
>> struct S1 {
>> var v1:Int = 0
>> }
>> MemoryLayout.size
>> //r1: Int =8
>>
>> struct S2: P {
>> var v2: Int
>> var x:Int
>> }
>> MemoryLayout .size
>> //r2: Int = 16
>>
>> ** Question:
>> Why we need to known the size of a object that can't be instanced?
>>
>> ** Confuse:
>> MemoryLayout .size
>> //r3: Int = 0
>>
>> MemoryLayout .size
>> //r4: Int = 16
>>
>>
>>
>> Xiaodi Wu via swift-evolution 于2016年8月5日
>> 周五16:34写道：
>>
>>> On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams 
>>> wrote:
>>>

 on Thu Aug 04 2016, Dmitri Gribenko  wrote:

 > On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution
 >  wrote:
 >> Could I suggest an alternative? It's conservative in that it mimics
 the
 >> relationships we had before the proposal was implemented and also
 maintains
 >> the simplicity of the caseless enum:
 >>
 >> ```
 >> extension MemoryLayout {
 >>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
 >>   // etc.
 >> }
 >> ```
 >
 > I like this API.  I think given all the alternatives that we explored,
 > it is better than those.  I also think that it nicely avoids the
 > following issue with the proposed MemoryLayout.of(type(of:
 > someExpression)).size syntax.
 >
 > Imagine that you have a value whose static type differs from the
 > dynamic type.  For example, a protocol existential:
 >
 > protocol P {}
 > extension Int : P {}
 > var x: P = 10
 >
 > The question is, what does MemoryLayout.of(type(of: x)).size compute,
 > size of the existential box, or the size of an Int instance?  The
 > semantics of 'type(of:)' are "return the dynamic type", so the
 > straightforward conclusion is that MemoryLayout.of(type(of: x)).size
 > returns the size of the dynamic type instance, of Int.
 >
 > What actually happens is that 'type(of: x)' returns a dynamic value of
 > 'Int.self', statically typed as 'P.Type'.  So P gets deduced for the
 > generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
 > x)).size returns the size of the protocol box.
 >
 > I think due to this complex interaction, using type(of:) might lead to
 > confusing code, and thus I like Xiaodi's approach better.
 >
 > Dmitri

 Okay, I'm convinced; that's what we should do.

>>>
>>> Proposal and stdlib PRs have both been created.
>>>
>>>
 --
 -Dave

>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Kevin Ballard via swift-evolution]

> On Aug 5, 2016, at 7:36 PM, Erica Sadun  wrote:
> 
> On Aug 5, 2016, at 8:10 PM, Kevin Ballard  > wrote:
>> 
>>> 
>>> On Aug 5, 2016, at 5:16 PM, Erica Sadun >> > wrote:
>>> 
>>> 
 On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
 > wrote:
 
> 
> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution 
> > wrote:
> 
> If all you want to do is get the localized description, then you can just 
> say `(error as NSError).localizedDescription`.
 
 Just ‘error.localizedDescription’ works now. That was part of SE-0112.
 
- Doug
>>> 
>>> Would it kill to allow:
>>> 
>>> let err = NSError()
>>> err.localizedDescription = "bad things happen"
>>> throw err
>>> 
>>> or even
>>> 
>>> throw NSError("Bad things happen")
>>> 
>>> for lightweight use? I ended up refactoring entirely to enum : Error 
>>> because Swift yelled at me for using NSError(): "this results in an invalid 
>>> NSError instance. It will raise an exception in a future release. Please 
>>> call errorWithDomain:code:userInfo: or initWithDomain:code:userInfo:. This 
>>> message shown only once."
>>> 
>>> enum Errors: Error {case bad}
>>> Errors.bad._code // 0
>>> Errors.bad._domain // "Errors"
>>> Errors.bad._userInfo // Optional({})
>>> Errors.bad.localizedDescription // "The operation couldn’t be completed. 
>>> (Errors error 0.)"
>>> 
>>> Bleh.
>> 
>> NSErrors need a domain/code. It doesn’t make much sense to throw one without 
>> it. And besides, there’s a fairly trivial solution for doing what you want 
>> to do:
>> 
>> struct GenericError: LocalizedError {
>> let message: String
>> init(_ message: String) {
>> self.message = message
>> }
>> var errorDescription: String? {
>> return message
>> }
>> }
>> 
>> Now you can just say `throw GenericError(“Bad things happen”)`.
>> 
>> -Kevin Ballard
> 
> I know I can build workarounds but if we're going to have the 
> error.localizedDescription, making it an initializable/assignable property 
> just seems like a nice thing™. Why can't we have nice things™?

I don’t actually think it’s a nice thing™ to have it be assignable like you 
ask, because we should be encouraging people to use typed errors. You may as 
well just ask for String to conform to Error (in fact, you could just add that 
conformance yourself and skip the GenericError wrapper entirely).

-Kevin___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A unified error handling mechanism?

[Anders Ha via swift-evolution]

> On 6 Aug 2016, at 7:50 AM, Fernando Rodríguez via swift-evolution 
>  wrote:
> 
> Hi,
> 
> I do a lot of training and one of the features of Swift that seems more 
> confusing to students (and myself) is error handling. There are too many ways 
> of doing it, and none seems satisfactory.
> 
> Let's take for example an initializer. There are 2 different ways of handling 
> errors within an init:
> 
> a) Old School: return nil. This was very simple in Objective C, because the 
> uncommon case of an error could be easily ignored...until everything crashed.
> 
> In Swift it's not easy (nor advisable IMHO) to completely ignore the 
> possibility of an error. Besides, it has 2 complications.
> 
> First of all, you return an Optional, and Optionals have a tendency to go 
> viral. Suddenly, all your code has to deal with optionals.
> 
> Secondly, you have no information about the error itself.
> 
> b) do/try/catch
> 
> This allows you to have information about the error, but also causes the 
> newly created object to be "trapped" inside a do block.

You can define an uninitialised variable outside the scope of `do`, and assign 
to it within the scope of `do`.


func test() throws -> Int { return 1 }

let variable: Int

do {
variable = try test()
} catch let error {
fatalError("\(error)")
}

print(variable)

> 
> Are there any plans to address this situation? I believe there should be a 
> single, obvious and convenient way of handling errors in the language.
> 
> What do you guys think?
> 
> 
> 
> -- 
> 
> 
> 
>  
> 
> Fernando Rodríguez
> m. +34 610 965 332
> t. +34 91 629 57 61
> fernando@k eepcoding.io 
>   
> KeepCoding.io
> 2120 University Avenue, Berkeley, CA
> 
> Avda. Fuencarral, 44, Ed. 8, Loft 30
> 28108 Alcobendas (Madrid) Spain
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: URL(fileURLWithPath:) to URL(filePath:)

[Chris Lattner via swift-evolution]

> On Aug 5, 2016, at 5:32 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> There are many, many of these and it would be great to find out how to 
> request them. I suspect the window of opportunity has passed for 
> code-breaking changes though.

Right.  We’ll have some limited ability to do source breaking changes in Swift 
4, but we need to figure out how the mitigation strategy will work (in full 
detail) so we know exactly what sort of changes will work.

-Chris


> 
> -- E
> 
>> On Aug 5, 2016, at 4:29 PM, Charles Srstka via swift-evolution 
>>  wrote:
>> 
>> Late, I know, but since it’s a simple search-and-replace change, I wonder if 
>> the team might consider renaming URL(fileURLWithPath:), which is quite 
>> verbose, to URL(filePath:), which conveys the same information while being 
>> much less painful to type.
>> 
>> Charles
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[Boris Wang via swift-evolution]

Addition:

I think protocol should't has size, or it's size should be zero.
Because you can't put the 40 bytes data in anywhere.


Boris Wang 于2016年8月6日 周六10:35写道：

> codes in swift REPL:
>
> protocol P {
> var x:Int {get}
> }
> MemoryLayout.size
> //r0 : Int = 40
>
> struct S1 {
> var v1:Int = 0
> }
> MemoryLayout.size
> //r1: Int =8
>
> struct S2: P {
> var v2: Int
> var x:Int
> }
> MemoryLayout .size
> //r2: Int = 16
>
> ** Question:
> Why we need to known the size of a object that can't be instanced?
>
> ** Confuse:
> MemoryLayout .size
> //r3: Int = 0
>
> MemoryLayout .size
> //r4: Int = 16
>
>
>
> Xiaodi Wu via swift-evolution 于2016年8月5日
> 周五16:34写道：
>
>> On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams 
>> wrote:
>>
>>>
>>> on Thu Aug 04 2016, Dmitri Gribenko  wrote:
>>>
>>> > On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution
>>> >  wrote:
>>> >> Could I suggest an alternative? It's conservative in that it mimics
>>> the
>>> >> relationships we had before the proposal was implemented and also
>>> maintains
>>> >> the simplicity of the caseless enum:
>>> >>
>>> >> ```
>>> >> extension MemoryLayout {
>>> >>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>>> >>   // etc.
>>> >> }
>>> >> ```
>>> >
>>> > I like this API.  I think given all the alternatives that we explored,
>>> > it is better than those.  I also think that it nicely avoids the
>>> > following issue with the proposed MemoryLayout.of(type(of:
>>> > someExpression)).size syntax.
>>> >
>>> > Imagine that you have a value whose static type differs from the
>>> > dynamic type.  For example, a protocol existential:
>>> >
>>> > protocol P {}
>>> > extension Int : P {}
>>> > var x: P = 10
>>> >
>>> > The question is, what does MemoryLayout.of(type(of: x)).size compute,
>>> > size of the existential box, or the size of an Int instance?  The
>>> > semantics of 'type(of:)' are "return the dynamic type", so the
>>> > straightforward conclusion is that MemoryLayout.of(type(of: x)).size
>>> > returns the size of the dynamic type instance, of Int.
>>> >
>>> > What actually happens is that 'type(of: x)' returns a dynamic value of
>>> > 'Int.self', statically typed as 'P.Type'.  So P gets deduced for the
>>> > generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
>>> > x)).size returns the size of the protocol box.
>>> >
>>> > I think due to this complex interaction, using type(of:) might lead to
>>> > confusing code, and thus I like Xiaodi's approach better.
>>> >
>>> > Dmitri
>>>
>>> Okay, I'm convinced; that's what we should do.
>>>
>>
>> Proposal and stdlib PRs have both been created.
>>
>>
>>> --
>>> -Dave
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Erica Sadun via swift-evolution]

On Aug 5, 2016, at 8:10 PM, Kevin Ballard  wrote:
> 
>> 
>> On Aug 5, 2016, at 5:16 PM, Erica Sadun > > wrote:
>> 
>> 
>>> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
 
 On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution 
 > wrote:
 
 If all you want to do is get the localized description, then you can just 
 say `(error as NSError).localizedDescription`.
>>> 
>>> Just ‘error.localizedDescription’ works now. That was part of SE-0112.
>>> 
>>> - Doug
>> 
>> Would it kill to allow:
>> 
>> let err = NSError()
>> err.localizedDescription = "bad things happen"
>> throw err
>> 
>> or even
>> 
>> throw NSError("Bad things happen")
>> 
>> for lightweight use? I ended up refactoring entirely to enum : Error because 
>> Swift yelled at me for using NSError(): "this results in an invalid NSError 
>> instance. It will raise an exception in a future release. Please call 
>> errorWithDomain:code:userInfo: or initWithDomain:code:userInfo:. This 
>> message shown only once."
>> 
>> enum Errors: Error {case bad}
>> Errors.bad._code // 0
>> Errors.bad._domain // "Errors"
>> Errors.bad._userInfo // Optional({})
>> Errors.bad.localizedDescription // "The operation couldn’t be completed. 
>> (Errors error 0.)"
>> 
>> Bleh.
> 
> NSErrors need a domain/code. It doesn’t make much sense to throw one without 
> it. And besides, there’s a fairly trivial solution for doing what you want to 
> do:
> 
> struct GenericError: LocalizedError {
> let message: String
> init(_ message: String) {
> self.message = message
> }
> var errorDescription: String? {
> return message
> }
> }
> 
> Now you can just say `throw GenericError(“Bad things happen”)`.
> 
> -Kevin Ballard

I know I can build workarounds but if we're going to have the 
error.localizedDescription, making it an initializable/assignable property just 
seems like a nice thing™. Why can't we have nice things™?

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[Boris Wang via swift-evolution]

codes in swift REPL:

protocol P {
var x:Int {get}
}
MemoryLayout.size
//r0 : Int = 40

struct S1 {
var v1:Int = 0
}
MemoryLayout.size
//r1: Int =8

struct S2: P {
var v2: Int
var x:Int
}
MemoryLayout .size
//r2: Int = 16

** Question:
Why we need to known the size of a object that can't be instanced?

** Confuse:
MemoryLayout .size
//r3: Int = 0

MemoryLayout .size
//r4: Int = 16



Xiaodi Wu via swift-evolution 于2016年8月5日
周五16:34写道：

> On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams  wrote:
>
>>
>> on Thu Aug 04 2016, Dmitri Gribenko  wrote:
>>
>> > On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution
>> >  wrote:
>> >> Could I suggest an alternative? It's conservative in that it mimics the
>> >> relationships we had before the proposal was implemented and also
>> maintains
>> >> the simplicity of the caseless enum:
>> >>
>> >> ```
>> >> extension MemoryLayout {
>> >>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>> >>   // etc.
>> >> }
>> >> ```
>> >
>> > I like this API.  I think given all the alternatives that we explored,
>> > it is better than those.  I also think that it nicely avoids the
>> > following issue with the proposed MemoryLayout.of(type(of:
>> > someExpression)).size syntax.
>> >
>> > Imagine that you have a value whose static type differs from the
>> > dynamic type.  For example, a protocol existential:
>> >
>> > protocol P {}
>> > extension Int : P {}
>> > var x: P = 10
>> >
>> > The question is, what does MemoryLayout.of(type(of: x)).size compute,
>> > size of the existential box, or the size of an Int instance?  The
>> > semantics of 'type(of:)' are "return the dynamic type", so the
>> > straightforward conclusion is that MemoryLayout.of(type(of: x)).size
>> > returns the size of the dynamic type instance, of Int.
>> >
>> > What actually happens is that 'type(of: x)' returns a dynamic value of
>> > 'Int.self', statically typed as 'P.Type'.  So P gets deduced for the
>> > generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
>> > x)).size returns the size of the protocol box.
>> >
>> > I think due to this complex interaction, using type(of:) might lead to
>> > confusing code, and thus I like Xiaodi's approach better.
>> >
>> > Dmitri
>>
>> Okay, I'm convinced; that's what we should do.
>>
>
> Proposal and stdlib PRs have both been created.
>
>
>> --
>> -Dave
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Kevin Ballard via swift-evolution]

> On Aug 5, 2016, at 5:16 PM, Erica Sadun  wrote:
> 
> 
>> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution 
>>> > wrote:
>>> 
>>> If all you want to do is get the localized description, then you can just 
>>> say `(error as NSError).localizedDescription`.
>> 
>> Just ‘error.localizedDescription’ works now. That was part of SE-0112.
>> 
>>  - Doug
> 
> Would it kill to allow:
> 
> let err = NSError()
> err.localizedDescription = "bad things happen"
> throw err
> 
> or even
> 
> throw NSError("Bad things happen")
> 
> for lightweight use? I ended up refactoring entirely to enum : Error because 
> Swift yelled at me for using NSError(): "this results in an invalid NSError 
> instance. It will raise an exception in a future release. Please call 
> errorWithDomain:code:userInfo: or initWithDomain:code:userInfo:. This message 
> shown only once."
> 
> enum Errors: Error {case bad}
> Errors.bad._code // 0
> Errors.bad._domain // "Errors"
> Errors.bad._userInfo // Optional({})
> Errors.bad.localizedDescription // "The operation couldn’t be completed. 
> (Errors error 0.)"
> 
> Bleh.

NSErrors need a domain/code. It doesn’t make much sense to throw one without 
it. And besides, there’s a fairly trivial solution for doing what you want to 
do:

struct GenericError: LocalizedError {
let message: String
init(_ message: String) {
self.message = message
}
var errorDescription: String? {
return message
}
}

Now you can just say `throw GenericError(“Bad things happen”)`.

-Kevin Ballard___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A unified error handling mechanism?

[Boris Wang via swift-evolution]

do/try/catch use the error handling mechanism, named exception.

I think we should use it carefully , it will results convoluted code and
the risk of exception safe.

Fernando Rodríguez 于2016年8月6日 周六07:50写道：

> Hi,
>
> I do a lot of training and one of the features of Swift that seems more
> confusing to students (and myself) is error handling. There are too many
> ways of doing it, and none seems satisfactory.
>
> Let's take for example an initializer. There are 2 different ways of
> handling errors within an init:
>
> a) Old School: return nil. This was very simple in Objective C, because
> the uncommon case of an error could be easily ignored...until everything
> crashed.
>
> In Swift it's not easy (nor advisable IMHO) to completely ignore the
> possibility of an error. Besides, it has 2 complications.
>
> First of all, you return an Optional, and Optionals have a tendency to go
> viral. Suddenly, all your code has to deal with optionals.
>
> Secondly, you have no information about the error itself.
>
> b) do/try/catch
>
> This allows you to have information about the error, but also causes the
> newly created object to be "trapped" inside a do block.
>
> Are there any plans to address this situation? I believe there should be a
> single, obvious and convenient way of handling errors in the language.
>
> What do you guys think?
>
>
>
> --
>
>
> * *
>
>
> *Fernando Rodríguez*
>
> m. +34 610 965 332
>
> t. +34 91 629 57 61
>
> fernando@k eepcoding.io
>
> [image: pastedGraphic.png] [image: pastedGraphic_1.png] [image:
> pastedGraphic_2.png]
>
> *KeepCoding.io*
>
> 2120 University Avenue, Berkeley, CA
>
>
> Avda. Fuencarral, 44, Ed. 8, Loft 30
>
> 28108 Alcobendas (Madrid) Spain
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: URL(fileURLWithPath:) to URL(filePath:)

[Charles Srstka via swift-evolution]

> On Aug 5, 2016, at 7:32 PM, Erica Sadun  wrote:
> 
> There are many, many of these and it would be great to find out how to 
> request them. I suspect the window of opportunity has passed for 
> code-breaking changes though.

I do, too, but I figured it doesn’t hurt to try. If there is some small chance 
that this can still be changed, it would save us all a nasty case of 
carpal-tunnel syndrome from typing this unnecessary construction all the way 
from now to eternity. “fileURLWithPath:” is extremely verbose and redundant for 
something that is used so often, and it's the one thing that I’ve always hated 
about the URL-based file APIs. I’m kicking myself for not thinking to request 
this earlier, but better late than never, I suppose.

Charles___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Charles Srstka via swift-evolution]

> On Aug 5, 2016, at 7:16 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> Would it kill to allow:
> 
> let err = NSError()
> err.localizedDescription = "bad things happen"
> throw err
> 
> or even
> 
> throw NSError("Bad things happen")

You can make something that can do that fairly easily:

struct TextualError: LocalizedError {
var errorString: String

init() {
self.init("")
}

init(_ string: String) {
self.errorString = string
}

var failureReason: String? {
return self.errorString
}
}

Then, you can just:

throw TextualError("Must Sterilize!”)

Or:

var error = TextualError()
error.failureReason = "Must Sterilize!”
throw error

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Pitch: URL(fileURLWithPath:) to URL(filePath:)

[Erica Sadun via swift-evolution]

There are many, many of these and it would be great to find out how to request 
them. I suspect the window of opportunity has passed for code-breaking changes 
though.

-- E

> On Aug 5, 2016, at 4:29 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> Late, I know, but since it’s a simple search-and-replace change, I wonder if 
> the team might consider renaming URL(fileURLWithPath:), which is quite 
> verbose, to URL(filePath:), which conveys the same information while being 
> much less painful to type.
> 
> Charles
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Erica Sadun via swift-evolution]

> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> 
>> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution 
>> > wrote:
>> 
>> If all you want to do is get the localized description, then you can just 
>> say `(error as NSError).localizedDescription`.
> 
> Just ‘error.localizedDescription’ works now. That was part of SE-0112.
> 
>   - Doug

Would it kill to allow:

let err = NSError()
err.localizedDescription = "bad things happen"
throw err

or even

throw NSError("Bad things happen")

for lightweight use? I ended up refactoring entirely to enum : Error because 
Swift yelled at me for using NSError(): "this results in an invalid NSError 
instance. It will raise an exception in a future release. Please call 
errorWithDomain:code:userInfo: or initWithDomain:code:userInfo:. This message 
shown only once."

enum Errors: Error {case bad}
Errors.bad._code // 0
Errors.bad._domain // "Errors"
Errors.bad._userInfo // Optional({})
Errors.bad.localizedDescription // "The operation couldn’t be completed. 
(Errors error 0.)"

Bleh.

-- E___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] A unified error handling mechanism?

[Fernando Rodríguez via swift-evolution]

Hi,

I do a lot of training and one of the features of Swift that seems more
confusing to students (and myself) is error handling. There are too many
ways of doing it, and none seems satisfactory.

Let's take for example an initializer. There are 2 different ways of
handling errors within an init:

a) Old School: return nil. This was very simple in Objective C, because the
uncommon case of an error could be easily ignored...until everything
crashed.

In Swift it's not easy (nor advisable IMHO) to completely ignore the
possibility of an error. Besides, it has 2 complications.

First of all, you return an Optional, and Optionals have a tendency to go
viral. Suddenly, all your code has to deal with optionals.

Secondly, you have no information about the error itself.

b) do/try/catch

This allows you to have information about the error, but also causes the
newly created object to be "trapped" inside a do block.

Are there any plans to address this situation? I believe there should be a
single, obvious and convenient way of handling errors in the language.

What do you guys think?



-- 


* *


*Fernando Rodríguez*

m. +34 610 965 332

t. +34 91 629 57 61

fernando@k eepcoding.io

[image: pastedGraphic.png] [image: pastedGraphic_1.png] [image:
pastedGraphic_2.png]

*KeepCoding.io*

2120 University Avenue, Berkeley, CA


Avda. Fuencarral, 44, Ed. 8, Loft 30

28108 Alcobendas (Madrid) Spain
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

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 NSError. However, there are no default 
implementations for errorDomain and errorCode, and there is no way to access 
the default values for _domain and _code that Error enums get in Swift. Thus, 
even if all one wanted to do was to provide a value for NSURLErrorKey, one has 
to do all this:

enum MyError: CustomNSError {
case foo(URL)
case bar(URL)
case baz(URL)

static var errorDomain: String {
return “com.MyCompany.MyApp.MyError”
}

var errorCode: Int {
switch self {
case .foo(_):
return 1
case .bar(_):
return 2
case .baz(_):
return 3
}
}

var errorUserInfo: [String : NSObject] {
// construct the actual user info
}
}

Notice how far down you have to read before you finally get to the part that 
constructs the interesting information.

PROPROSED SOLUTION:

Add default implementations for all the properties in CustomNSError.

DETAILED DESIGN:

The implementations for errorCode and errorDomain will simply provide the 
default values of _code and _domain already provided by Swift enums. The 
default implementation for errorUserInfo will simply return an empty dictionary.

This would allow the above enum to be written simply as:

enum MyError: CustomNSError {
case foo(URL)
case bar(URL)
case baz(URL)

var errorUserInfo: [String : NSObject] {
// construct the actual user info
}
}

and the frameworks would provide something appropriate for the domain and code.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Pitch: URL(fileURLWithPath:) to URL(filePath:)

[Charles Srstka via swift-evolution]

Late, I know, but since it’s a simple search-and-replace change, I wonder if 
the team might consider renaming URL(fileURLWithPath:), which is quite verbose, 
to URL(filePath:), which conveys the same information while being much less 
painful to type.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [META] Gmane and Swift Evolution

[Erica Sadun via swift-evolution]

And we're done for now! Thanks all. 

-- E

> On Aug 3, 2016, at 9:18 PM, Saagar Jha  wrote:
> 
> I’ve submitted a pull that includes everything except for SE-0094, 0095, and 
> 0110, which I wasn’t able to find.
> 
> Saagar Jha
> 
> 
> 
>> On Aug 3, 2016, at 11:31, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Aug 2, 2016, at 9:22 AM, Ben Rimmington >> > wrote:
>>> 
>>> 
 On 2 Aug 2016, at 16:16, Erica Sadun via swift-evolution 
 > wrote:
 
 Anyone willing to adopt a proposal or a group and get them updated, please 
 reply in-thread and submit a PR with changes.
>>> 
>>> [SE-0076 ... SE-0090] >> >
>>> 
>>> -- Ben
>>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Kevin Ballard via swift-evolution]

If all you want to do is get the localized description, then you can
just say `(error as NSError).localizedDescription`.

-Kevin

On Fri, Aug 5, 2016, at 02:59 AM, Jean-Daniel Dupas wrote:
>
>> Le 5 août 2016 à 05:12, Kevin Ballard via swift-evolution > evolut...@swift.org> a écrit :
>>
>> With NSError, you *must* check the domain before trying to interpret
>> the code, or else your code is buggy and will behave incorrectly when
>> receiving an unexpected error.
>
> You must check before interpreting the code, but you don’t have to
> interpret the code to do something useful with an NSError.
>
> I think what Jon is looking for is ‘LocalizedError’ and
> ‘CustomNSError’.
> Is there any guarantee that casting an NSError into a CustomNSError or
> LocalizedError will always succeed ?
>
>> With SE-0112, instead of checking the domain, you check if the Error
>> can be casted to the particular error type that represents the
>> domain. There is a one-to-one correspondence between domains and the
>> new error types. For example, NSCocoaErrorDomain is represented by
>> CocoaError, NSURLErrorDomain is URLError, etc.
>>
>> So previously you might have code that looks like
>>
>> func handleError(error: NSError) {
>> switch error.domain {
>> case NSCocoaErrorDomain where error.code ==
>> NSFileNoSuchFileError:
>> let path = error.userInfo[NSFilePathErrorKey] as? String
>> // handle error for path
>> case NSURLErrorDomain where error.code == NSURLErrorTimedOut:
>> let url = error.userInfo[NSURLErrorKey] as? NSURL
>> // handle error for url
>> default:
>> // generic handling of other errors
>> }
>> }
>>
>> And now you'd write that like
>>
>> func handleError(error: Error) {
>> switch error {
>> case let error as CocoaError where error.code ==
>> .fileNoSuchFileError:
>> let path = error.filePath
>> // handle error for path
>> case let error as URLError where error.code == .timedOut:
>> let url = error.failingURL
>> // handle error for url
>> default:
>> // generic handling of other errors
>> }
>> }
>>
>> It's the same basic structure, except now you get strong typing, you
>> can't possibly forget to check the domain (which is a surprisingly
>> common bug I see in a lot of code), and you get convenient accessors
>> for the values stored in the user info.
>>
>> And if you don't actually care about any of the user info properties,
>> then the new version is much simpler than the old:
>>
>> func handleError(error: Error) {
>> switch error {
>> case CocoaError.fileNoSuchFileError:
>> // handle error
>> case URLError.timedOut:
>> // handle error
>> default:
>> // generic handling of other errors
>> }
>> }
>>
>> It's similar to checking the code without the domain in the old
>> style, except now it checks the domain automatically, so you *still*
>> can't accidentally interpret an error's code in the wrong domain.
>>
>> -Kevin Ballard
>>
>> On Thu, Aug 4, 2016, at 11:00 AM, Jon Shier via swift-
>> evolution wrote:
>>> Doug:
>>> Thanks for indulging me so far, I think I’ve almost got it. Prior to
>>> this, using NSError, I could just look at the relevant properties of
>>> the error if I needed to see what type it was. Network errors had
>>> different codes from CloudKit errors, POSIX errors were underlying
>>> FileManager errors. A bit complex due to the undocumented nature of
>>> so many of these errors, but I could ignore any aspect of the error
>>> I didn’t care about. Now, however, it seems I must always care about
>>> what types of errors come out of various methods, as I’ll need to
>>> cast to the appropriate types to get useful information. For
>>> example, how would you handle the CloudKit errors I mentioned
>>> before? It seems to me like I would need to, at the point where I
>>> need to extract useful information, do a switch on various casts.
>>> First, try casting to CKError, then to CocoaError (?), and then
>>> likely produce a fatalError if there’s an unexpected type. Or is
>>> Error guaranteed to always cast to something useful? I’ve read the
>>> proposal a few times now and it looks like a lot of casting is going
>>> to be required, I’m mostly curious about the recommended patterns,
>>> especially for asynchronous calls that don’t go through throw/catch.
>>>
>>>
>>>
>>> Jon
>>>
>>>
 On Aug 2, 2016, at 5:36 PM, Douglas Gregor 
 wrote:


> On Aug 2, 2016, at 2:19 PM, Jon Shier  wrote:
>
> Thanks Doug. I missed the rename, as earlier points still referred
> to ErrorProtocol. In regards to the CloudKit errors, I appreciate
> the strongly typed CKError, but why not have the methods return
> that type directly?

 Generally speaking, Cocoa only uses NSError—not specific subclasses
 or NSError or other error types—because errors can occur at many
 different 

Re: [swift-evolution] Improved value and move semantics

[Johannes Neubauer via swift-evolution]

> Am 05.08.2016 um 17:17 schrieb Joe Groff :
> 
>> 
>> On Aug 4, 2016, at 11:31 AM, Johannes Neubauer  wrote:
>> 
>>> 
>>> Am 04.08.2016 um 20:21 schrieb Joe Groff :
>>> 
 
 On Aug 4, 2016, at 11:20 AM, Johannes Neubauer  
 wrote:
 
 
> Am 04.08.2016 um 17:26 schrieb Matthew Johnson via swift-evolution 
> :
> 
>> 
>> On Aug 4, 2016, at 9:39 AM, Joe Groff  wrote:
>> 
>>> 
>>> On Aug 3, 2016, at 8:46 PM, Chris Lattner  wrote:
>>> 
>>> On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
>>> 
>>> a. We indirect automatically based on some heuristic, as an
>>> optimization.
> 
> I weakly disagree with this, because it is important that we provide 
> a predictable model.  I’d rather the user get what they write, and 
> tell people to write ‘indirect’ as a performance tuning option.  “Too 
> magic” is bad.
 
 I think 'indirect' structs with a heuristic default are important to 
 the way people are writing Swift in practice. We've seen many users 
 fully invest in value semantics types, because they wants the benefits 
 of isolated state, without appreciating the code size and performance 
 impacts. Furthermore, implementing 'indirect' by hand is a lot of 
 boilerplate. Putting indirectness entirely in users' hands feels to me 
 a lot like the "value if word sized, const& if struct" heuristics C++ 
 makes you internalize, since there are similar heuristics where 
 'indirect' is almost always a win in Swift too.
>>> 
>>> I understand with much of your motivation, but I still disagree with 
>>> your conclusion.  I see this as exactly analogous to the situation and 
>>> discussion when we added indirect to enums.  At the time, some argued 
>>> for a magic model where the compiler figured out what to do in the most 
>>> common “obvious” cases.
>>> 
>>> We agreed to use our current model though because:
>>> 1) Better to be explicit about allocations & indirection that implicit.
>>> 2) The compiler can guide the user in the “obvious” case to add the 
>>> keyword with a fixit, preserving the discoverability / ease of use.
>>> 3) When indirection is necessary, there are choices to make about where 
>>> the best place to do it is.
>>> 4) In the most common case, the “boilerplate” is a single “indirect” 
>>> keyword added to the enum decl itself.  In the less common case, you 
>>> want the “boilerplate” so that you know where the indirections are 
>>> happening.
>>> 
>>> Overall, I think this model has worked well for enums and I’m still 
>>> very happy with it.  If you generalize it to structs, you also have to 
>>> consider that this should be part of a larger model that includes 
>>> better support for COW.  I think it would be really unfortunate to 
>>> “magically indirect” struct, when the right answer may actually be to 
>>> COW them instead.  I’d rather have a model where someone can use:
>>> 
>>> // simple, predictable, always inline, slow in some cases.
>>> struct S1 { … }
>>> 
>>> And then upgrade to one of:
>>> 
>>> indirect struct S2 {…}
>>> cow struct S3 { … }
>>> 
>>> Depending on the structure of their data.  In any case, to reiterate, 
>>> this really isn’t the time to have this debate, since it is clearly 
>>> outside of stage 1.
>> 
>> In my mind, indirect *is* cow. An indirect struct without value 
>> semantics is a class, so there would be no reason to implement 
>> 'indirect' for structs without providing copy-on-write behavior.
> 
> This is my view as well.  Chris, what is the distinction in your mind?
> 
>> I believe that the situation with structs and enums is also different. 
>> Indirecting enums has a bigger impact on interface because they enable 
>> recursive data structures, and while there are places where indirecting 
>> a struct may make new recursion possible, that's much rarer of a reason 
>> to introduce indirectness for structs. Performance and code size are the 
>> more common reasons, and we've described how to build COW boxes manually 
>> to work around performance problems at the last two years' WWDC. There 
>> are pretty good heuristics for when indirection almost always beats 
>> inline storage: once you have more than one refcounted field, passing 
>> around a box and retaining once becomes cheaper than retaining the 
>> fields individually. Once you exceed the fixed-sized buffer threshold of 
>> three words, indirecting some or all of your fields becomes necessary to 
>> avoid falling off a cliff in 

Re: [swift-evolution] Improved value and move semantics

[Dave Abrahams via swift-evolution]

on Wed Aug 03 2016, Chris Lattner  wrote:

>> On Aug 3, 2016, at 8:46 PM, Chris Lattner via swift-evolution
>>  wrote:
>> 
>> On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
>> 
>
>> a. We indirect automatically based on some heuristic, as an
>> optimization.
 
 I weakly disagree with this, because it is important that we
 provide a predictable model.  I’d rather the user get what they
 write, and tell people to write ‘indirect’ as a performance tuning
 option.  “Too magic” is bad.
>>> 
>>> I think 'indirect' structs with a heuristic default are important
>>> to the way people are writing Swift in practice. We've seen many
>>> users fully invest in value semantics types, because they wants the
>>> benefits of isolated state, without appreciating the code size and
>>> performance impacts. Furthermore, implementing 'indirect' by hand
>>> is a lot of boilerplate. Putting indirectness entirely in users'
>>> hands feels to me a lot like the "value if word sized, const& if
>>> struct" heuristics C++ makes you internalize, since there are
>>> similar heuristics where 'indirect' is almost always a win in Swift
>>> too.
>> 
>> I understand with much of your motivation, but I still disagree with your 
>> conclusion.
>
> ^I understand and agree with much of your motivation...
>
> -Chris
>
>>  I see this as exactly analogous to the situation and discussion
>> when we added indirect to enums.  At the time, some argued for a
>> magic model where the compiler figured out what to do in the most
>> common “obvious” cases.
>> 
>> We agreed to use our current model though because:
>> 1) Better to be explicit about allocations & indirection that implicit.  
>> 2) The compiler can guide the user in the “obvious” case to add the
>> keyword with a fixit, preserving the discoverability / ease of use.
>> 3) When indirection is necessary, there are choices to make about
>> where the best place to do it is.
>> 4) In the most common case, the “boilerplate” is a single “indirect”
>> keyword added to the enum decl itself.  In the less common case, you
>> want the “boilerplate” so that you know where the indirections are
>> happening.
>> 
>> Overall, I think this model has worked well for enums and I’m still
>> very happy with it.  If you generalize it to structs, you also have
>> to consider that this should be part of a larger model that includes
>> better support for COW.  I think it would be really unfortunate to
>> “magically indirect” struct, when the right answer may actually be
>> to COW them instead.  

COW'ing the struct is implied by indirecting it.  You're not allowed to
break its value semantics just because it's being stored indirectly, and
we're darned sure not going to introduce an eagerly copied box there; I
think we all agree that the eager boxes we currently have must evolve
into COWs before ABI stability sets in.

>> I’d rather have a model where someone can use:
>> 
>> // simple, predictable, always inline, slow in some cases.
>> struct S1 { … }  
>> 
>> And then upgrade to one of:
>> 
>> indirect struct S2 {…}
>> cow struct S3 { … } 
>> 
>> Depending on the structure of their data.  In any case, to
>> reiterate, this really isn’t the time to have this debate, since it
>> is clearly outside of stage 1.

Well, I don't want to draw it out either, but I do want to add one
point: the “predictable performance” argument rings pretty hollow for
me.  There are already hard-to-anticipate performance cliffs wherever we
have an inline buffer (e.g. existentials), an opportunity for stack
promotion, or where we mutate a COW data structure that might turn out
to have non-uniquely-referenced storage.  All of these effects add up to
code that performs well without too much intervention in most cases. We
should continue to make Swift perform well automatically, and give
people the tools they need to make adjustments when profiling reveals an
issue.

-- 
-Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Taras Zakharko via swift-evolution]

You could use the pointer/raw memory API to implement that. 

One reason why I dislike the idea of introducing fixed-size arrays as a 
first-class language feature is that it adds an additional construct with quite 
niche use. Non-type generic parameters instead give you a powerful tool that 
you can use to implement all kinds of things. 

BTW, another way to have fixed-size arrays would be to extend the tuple type. 
However, if i understand correctly, the biggest optimisation potential comes 
from knowing the size of the array at the compile time. So we do need some sort 
of specialisation parameter. 

Best, 

 Taras

> I don't think that non-type generic arguments are enough to create fixed-size 
> arrays. How would you fill in `struct Vector{ ... }`?
> 
> Seems to me that the first step would be actual language support for 
> non-parametrizable fixed-size arrays.
> 
> Félix
> > Le 5 août 2016 à 04:53:20, Taras Zakharko via 
> > swift-evolutiona
> >  écrit :
> > 
> > 
> > > A few things immediately spring to mind:
> > > • Fixed-size arrays
> > > • An optimized Matrix type
> > > • Swifty syntax for Fourier transforms
> > > • A numerical integrator (or diff-eq solver!)
> > > • BigInt capabilities
> > > 
> > > The first of these (fixed-size arrays) will probably require compiler 
> > > support.
> > 
> > Fixed-size arrays should be easy enough to implement if the Swift generics 
> > are enhanced with support for constraints beyond type variables. E.g.
> > 
> > struct Vector{ … }
> > 
> > var x : Vector
> > 
> > or even
> > 
> > struct SparseTensor{ … }
> > 
> > var x: SparseTensor= 
> > SparseTensor(withValue: 0)
> > 
> > I believe that something like this was mentioned in the discussion of the 
> > Generics Manifesto. If you are interested in making Swift more suitable for 
> > numerical operations, I’d say that the first order of business is to work 
> > towards implementing this sort of generic constants.
> > 
> > Best,
> > 
> > Taras
> > 
> > > 
> > > The rest can already be done in a library, except I believe they will hit 
> > > the “generics cannot be specialized across module boundaries” slowdown, 
> > > and must be explicitly specialized for common numeric types to avoid it. 
> > > (Has this been fixed yet? Are there plans to?)
> > > 
> > > Nevin
> > > 
> > > 
> > > 
> > > On Wed, Aug 3, 2016 at 8:41 AM, Björn 
> > > Forsterwrote:
> > > > Hello Swift community,
> > > > to make use of Swift more appealing and useful for science, engineering 
> > > > and finance and everything else involving actually calculating things, 
> > > > I think it would be a big step forward if Swift would ship with its own 
> > > > math/numerics library.
> > > > 
> > > > Wouldn't it be great if Swift would offer functionality similar to 
> > > > Numpy in its native math lib? It think it would be great to have a 
> > > > "standard" annotation for vector arithmetic that the Swift community 
> > > > has agreed on and that scientific packages can build on.
> > > > 
> > > > Which functionality should be covered by a Swift's math lib and where 
> > > > should be drawn the line?
> > > > 
> > > > Any thoughts?
> > > > 
> > > > (If it is not the right time now to talk this topic, as it is not 
> > > > mentioned in the goals for Swift 4 by Chris, I apologize for bringing 
> > > > this up now. But I think then this should be discussed later at some 
> > > > point not in the infinite future)
> > > > 
> > > > Björn
> > > > ___
> > > > swift-evolution mailing list
> > > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)(mailto:swift-evolution@swift.org)
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > > > 
> > > 
> > > 
> > > 
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Tino Heth via swift-evolution]

> I don't think that non-type generic arguments are enough to create fixed-size 
> arrays. How would you fill in `struct Vector { ... }`?
Fixed-size arrays could be initialized like current arrays:
You either give a value to repeat or an array-literal of the right size.
There could be a faillable initializer that takes an array of undefined size as 
well.

The data could be stored in a "normal" array, but I'd expect an implementation 
in the stdlib, so that working with raw memory would stay something that's not 
needed for most Swift developers.

> Seems to me that the first step would be actual language support for 
> non-parametrizable fixed-size arrays.
Are you referring to literals here?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Something lightweight to discuss: improvement to print(_:separator:terminator:) ?

[Brandon Knope via swift-evolution]

One thing about print that I find odd to look at is when you don't want to use 
a line break: 

print(someValue, terminator: "") 

What if we used an enum for these options, especially for the two most common 
ones?

enum PrintTerminatorTypes {
case none
case lineBreak //default
case custom(String)
}

print(someValue, terminator: .none)
print(someValue, terminator: .lineBreak)
print(someValue, terminator: .custom(" --- "))

This seems clearer and more self documenting. 

Obviously this isn't a really important change but:
1. Swift-Evo seems light lately so why not discuss something...especially 
something really lightweight 
2. It's source breaking (...but it could be offered as an override?)

Brandon 

Sent from my iPad___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improved value and move semantics

[Joe Groff via swift-evolution]

> On Aug 4, 2016, at 11:31 AM, Johannes Neubauer  wrote:
> 
>> 
>> Am 04.08.2016 um 20:21 schrieb Joe Groff :
>> 
>>> 
>>> On Aug 4, 2016, at 11:20 AM, Johannes Neubauer  
>>> wrote:
>>> 
>>> 
 Am 04.08.2016 um 17:26 schrieb Matthew Johnson via swift-evolution 
 :
 
> 
> On Aug 4, 2016, at 9:39 AM, Joe Groff  wrote:
> 
>> 
>> On Aug 3, 2016, at 8:46 PM, Chris Lattner  wrote:
>> 
>> On Aug 3, 2016, at 7:57 PM, Joe Groff  wrote:
>> 
>> a. We indirect automatically based on some heuristic, as an
>> optimization.
 
 I weakly disagree with this, because it is important that we provide a 
 predictable model.  I’d rather the user get what they write, and tell 
 people to write ‘indirect’ as a performance tuning option.  “Too 
 magic” is bad.
>>> 
>>> I think 'indirect' structs with a heuristic default are important to 
>>> the way people are writing Swift in practice. We've seen many users 
>>> fully invest in value semantics types, because they wants the benefits 
>>> of isolated state, without appreciating the code size and performance 
>>> impacts. Furthermore, implementing 'indirect' by hand is a lot of 
>>> boilerplate. Putting indirectness entirely in users' hands feels to me 
>>> a lot like the "value if word sized, const& if struct" heuristics C++ 
>>> makes you internalize, since there are similar heuristics where 
>>> 'indirect' is almost always a win in Swift too.
>> 
>> I understand with much of your motivation, but I still disagree with 
>> your conclusion.  I see this as exactly analogous to the situation and 
>> discussion when we added indirect to enums.  At the time, some argued 
>> for a magic model where the compiler figured out what to do in the most 
>> common “obvious” cases.
>> 
>> We agreed to use our current model though because:
>> 1) Better to be explicit about allocations & indirection that implicit.
>> 2) The compiler can guide the user in the “obvious” case to add the 
>> keyword with a fixit, preserving the discoverability / ease of use.
>> 3) When indirection is necessary, there are choices to make about where 
>> the best place to do it is.
>> 4) In the most common case, the “boilerplate” is a single “indirect” 
>> keyword added to the enum decl itself.  In the less common case, you 
>> want the “boilerplate” so that you know where the indirections are 
>> happening.
>> 
>> Overall, I think this model has worked well for enums and I’m still very 
>> happy with it.  If you generalize it to structs, you also have to 
>> consider that this should be part of a larger model that includes better 
>> support for COW.  I think it would be really unfortunate to “magically 
>> indirect” struct, when the right answer may actually be to COW them 
>> instead.  I’d rather have a model where someone can use:
>> 
>> // simple, predictable, always inline, slow in some cases.
>> struct S1 { … }
>> 
>> And then upgrade to one of:
>> 
>> indirect struct S2 {…}
>> cow struct S3 { … }
>> 
>> Depending on the structure of their data.  In any case, to reiterate, 
>> this really isn’t the time to have this debate, since it is clearly 
>> outside of stage 1.
> 
> In my mind, indirect *is* cow. An indirect struct without value semantics 
> is a class, so there would be no reason to implement 'indirect' for 
> structs without providing copy-on-write behavior.
 
 This is my view as well.  Chris, what is the distinction in your mind?
 
> I believe that the situation with structs and enums is also different. 
> Indirecting enums has a bigger impact on interface because they enable 
> recursive data structures, and while there are places where indirecting a 
> struct may make new recursion possible, that's much rarer of a reason to 
> introduce indirectness for structs. Performance and code size are the 
> more common reasons, and we've described how to build COW boxes manually 
> to work around performance problems at the last two years' WWDC. There 
> are pretty good heuristics for when indirection almost always beats 
> inline storage: once you have more than one refcounted field, passing 
> around a box and retaining once becomes cheaper than retaining the fields 
> individually. Once you exceed the fixed-sized buffer threshold of three 
> words, indirecting some or all of your fields becomes necessary to avoid 
> falling off a cliff in unspecialized generic or protocol-type-based code. 
>  Considering that we hope to explore other layout optimizations, such as 
> automatically reordering 

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Félix Cloutier via swift-evolution]

I don't think that non-type generic arguments are enough to create fixed-size 
arrays. How would you fill in `struct Vector { ... }`?

Seems to me that the first step would be actual language support for 
non-parametrizable fixed-size arrays.

Félix

> Le 5 août 2016 à 04:53:20, Taras Zakharko via swift-evolution 
>  a écrit :
> 
> 
> 
>> A few things immediately spring to mind:
>> • Fixed-size arrays
>> • An optimized Matrix type
>> • Swifty syntax for Fourier transforms
>> • A numerical integrator (or diff-eq solver!)
>> • BigInt capabilities
>> 
>> The first of these (fixed-size arrays) will probably require compiler 
>> support.
> 
> Fixed-size arrays should be easy enough to implement if the Swift generics 
> are enhanced with support for constraints beyond type variables. E.g.
> 
>  struct Vector { … } 
> 
>  var x : Vector
> 
> or even 
> 
> struct SparseTensor { … }
> 
> var x: SparseTensor = 
> SparseTensor(withValue: 0)
> 
> I believe that something like this was mentioned in the discussion of the 
> Generics Manifesto. If you are interested in making Swift more suitable for 
> numerical operations, I’d say that the first order of business is to work 
> towards implementing this sort of generic constants. 
> 
> Best, 
> 
> Taras
> 
>> 
>> The rest can already be done in a library, except I believe they will hit 
>> the “generics cannot be specialized across module boundaries” slowdown, and 
>> must be explicitly specialized for common numeric types to avoid it. (Has 
>> this been fixed yet? Are there plans to?)
>> 
>> Nevin
>> 
>> 
>> 
>> On Wed, Aug 3, 2016 at 8:41 AM, Björn 
>> Forsterwrote:
>>> Hello Swift community,
>>> to make use of Swift more appealing and useful for science, engineering and 
>>> finance and everything else involving actually calculating things, I think 
>>> it would be a big step forward if Swift would ship with its own 
>>> math/numerics library.
>>> 
>>> Wouldn't it be great if Swift would offer functionality similar to Numpy in 
>>> its native math lib? It think it would be great to have a "standard" 
>>> annotation for vector arithmetic that the Swift community has agreed on and 
>>> that scientific packages can build on.
>>> 
>>> Which functionality should be covered by a Swift's math lib and where 
>>> should be drawn the line?
>>> 
>>> Any thoughts?
>>> 
>>> (If it is not the right time now to talk this topic, as it is not mentioned 
>>> in the goals for Swift 4 by Chris, I apologize for bringing this up now. 
>>> But I think then this should be discussed later at some point not in the 
>>> infinite future)
>>> 
>>> Björn
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org(mailto:swift-evolution@swift.org)
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] return if / return unless

[Julian Dunskus via swift-evolution]

I don’t agree with that. To me, everything between return and if (including the 
return itself) only being executed if the condition is true seems like the 
logical way of interpreting that syntax.

I do, however, see how people skimming through code might be confused, but a 
return with code after it should make it obvious that there’s more to it than 
always returning at that point.

> On 05 Aug 2016, at 04:58, rintaro ishizaki  wrote:
> 
> Limiting for `return` introduces another problem.
> 
> mutating func increment() -> Val {
>   self = self.incremented()
>   return self
> }
> 
> return val.increment() if val == sentinel
> print(val)
> 
> I think, it's not obvious `val` after `return ... if` is incremented or not.
> 
> 
> 2016-08-05 9:11 GMT+09:00 Julian Dunskus via swift-evolution 
> >:
> On 05 Aug 2016, at 01:24, Brent Royal-Gordon  > wrote:
> >
> >> On Aug 4, 2016, at 6:38 AM, Julian Dunskus via swift-evolution 
> >> > wrote:
> >>
> >> return nil unless let thing = things[index]
> >
> > On the `unless` part, at least, see the "Rename guard to unless" section in 
> > Commonly Rejected Changes: 
> >  > >
> >
> 
> I read that, see paragraph three of the email you replied to (my second in 
> this thread)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

[Taras Zakharko via swift-evolution]

> A few things immediately spring to mind:
> • Fixed-size arrays
> • An optimized Matrix type
> • Swifty syntax for Fourier transforms
> • A numerical integrator (or diff-eq solver!)
> • BigInt capabilities
> 
> The first of these (fixed-size arrays) will probably require compiler support.

Fixed-size arrays should be easy enough to implement if the Swift generics are 
enhanced with support for constraints beyond type variables. E.g.

  struct Vector { … } 

  var x : Vector

or even 

 struct SparseTensor { … }

 var x: SparseTensor = 
SparseTensor(withValue: 0)

I believe that something like this was mentioned in the discussion of the 
Generics Manifesto. If you are interested in making Swift more suitable for 
numerical operations, I’d say that the first order of business is to work 
towards implementing this sort of generic constants. 

Best, 

 Taras

> 
> The rest can already be done in a library, except I believe they will hit the 
> “generics cannot be specialized across module boundaries” slowdown, and must 
> be explicitly specialized for common numeric types to avoid it. (Has this 
> been fixed yet? Are there plans to?)
> 
> Nevin
> 
> 
> 
> On Wed, Aug 3, 2016 at 8:41 AM, Björn 
> Forsterwrote:
> > Hello Swift community,
> > to make use of Swift more appealing and useful for science, engineering and 
> > finance and everything else involving actually calculating things, I think 
> > it would be a big step forward if Swift would ship with its own 
> > math/numerics library.
> > 
> > Wouldn't it be great if Swift would offer functionality similar to Numpy in 
> > its native math lib? It think it would be great to have a "standard" 
> > annotation for vector arithmetic that the Swift community has agreed on and 
> > that scientific packages can build on.
> > 
> > Which functionality should be covered by a Swift's math lib and where 
> > should be drawn the line?
> > 
> > Any thoughts?
> > 
> > (If it is not the right time now to talk this topic, as it is not mentioned 
> > in the goals for Swift 4 by Chris, I apologize for bringing this up now. 
> > But I think then this should be discussed later at some point not in the 
> > infinite future)
> > 
> > Björn
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> > 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

[Patrick Pijnappel via swift-evolution]

I'm not very familiar with the runtime so forgive me – the protocols would
only have to be added once right? And couldn't this usually be done at
compile time, or does it happen when the module is linked at startup?

On Thu, Aug 4, 2016 at 4:36 PM, Haravikk via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 4 Aug 2016, at 03:19, Brent Royal-Gordon via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On Aug 3, 2016, at 10:17 AM, Manav Gabhawala via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> I was wondering why this would put any more of a burden on the runtime
> >> than simple inheritance of protocols. The way this could be
> >> implemented is to augment the ConformanceTable for nominal types by
> >> looking up its protocol extension’s inheritance clauses. I can
> >> definitely see this impacting compile time but I don’t see why runtime
> >> performance will be any different than simple inheritance. Further,
> >> cyclic chains can be detected and broken (compiler error) during the
> >> second pass of semantic analysis.
> >
> > My understanding—which may be incorrect, by the way—is that the issue is
> mainly with protocol extensions adding conformances, not specifically with
> those conformances being conditional, and that it specifically has to do
> with `is` and `as?` checks across module boundaries.
> >
> > Suppose you have these declarations in module M:
> >
> >   public protocol AProtocol {…}
> >   public protocol BProtocol: AProtocol {…}
> >   public protocol CProtocol {…}
> >
> >   // Public or otherwise doesn't matter here.
> >   public struct Foo: BProtocol {…}
> >
> > Foo essentially has a flat list of the protocols it conforms to attached
> to it. Notionally, you can think of that list as looking like:
> >
> >   Foo.self.conformsTo = [BProtocol.self, AProtocol.self]
> >
> > And when you write `foo is CProtocol`, that eventually translates into:
> >
> >   foo.dynamicType.conformsTo.contains(CProtocol.self)
> >
> > For a `Foo`, since the `conformsTo` list doesn't include
> `CProtocol.self`, it returns `false`.
> >
> > Now imagine that you write a new module, N, and in it you say:
> >
> >   extension Foo: CProtocol {…}
> >
> > You have now retroactively conformed `Foo` to `CProtocol`. Swift needs
> to reach into module M and add `CProtocol.self` to the
> `Foo.self.conformsTo` list. This is perfectly doable for a concrete
> type—it's one flat list, after all.
> >
> > Instead, though, imagine that module N extended `AProtocol` to add a
> conformance:
> >
> >   extension AProtocol: CProtocol {…}
> >
> > There are two ways to handle this. One is to find all types conforming
> to `AProtocol`, recursively, and add `CProtocol.self` to their conformance
> list. The other is to scrap the flat list of conformances and instead make
> `is` and `as?` recursively search each protocol. Either way, you have
> replaced a fast, flat operation with a slow, recursive one.
> >
> > Conditional conformance adds another wrinkle to this, of course—you must
> not only recursively search the list, but also evaluate the condition to
> see if it applies in this case. But the general problem of having to
> replace a fast search with a slow search applies either way.
>
> Great explanation! This switch from flat to recursively searched though
> seems like it would only occur when the extension is in an external module
> though; for internal modules would it not still be possible to determine
> the flat list for each type? In that case extending a type from another
> module could be either disallowed, or produce a warning to indicate the
> performance implication?
>
> The feature would still be very useful even just for internal use after
> all. Also it seems useful on a relatively small number of types, and the
> number of external modules that need/want to do this must narrow that even
> further, so external extensions may be quite niche, i.e- not worth losing
> the feature for internal use if that is indeed easier?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Jean-Daniel Dupas via swift-evolution]

> Le 5 août 2016 à 05:12, Kevin Ballard via swift-evolution 
>  a écrit :
> 
> With NSError, you must check the domain before trying to interpret the code, 
> or else your code is buggy and will behave incorrectly when receiving an 
> unexpected error. 

You must check before interpreting the code, but you don’t have to interpret 
the code to do something useful with an NSError. 

I think what Jon is looking for is ‘LocalizedError’ and ‘CustomNSError’.
Is there any guarantee that casting an NSError into a CustomNSError or 
LocalizedError will always succeed ?

> With SE-0112, instead of checking the domain, you check if the Error can be 
> casted to the particular error type that represents the domain. There is a 
> one-to-one correspondence between domains and the new error types. For 
> example, NSCocoaErrorDomain is represented by CocoaError, NSURLErrorDomain is 
> URLError, etc.
> 
> So previously you might have code that looks like
> 
> func handleError(error: NSError) {
> switch error.domain {
> case NSCocoaErrorDomain where error.code == NSFileNoSuchFileError:
> let path = error.userInfo[NSFilePathErrorKey] as? String
> // handle error for path
> case NSURLErrorDomain where error.code == NSURLErrorTimedOut:
> let url = error.userInfo[NSURLErrorKey] as? NSURL
> // handle error for url
> default:
> // generic handling of other errors
> }
> }
> 
> And now you'd write that like
> 
> func handleError(error: Error) {
> switch error {
> case let error as CocoaError where error.code == .fileNoSuchFileError:
> let path = error.filePath
> // handle error for path
> case let error as URLError where error.code == .timedOut:
> let url = error.failingURL
> // handle error for url
> default:
> // generic handling of other errors
> }
> }
> 
> It's the same basic structure, except now you get strong typing, you can't 
> possibly forget to check the domain (which is a surprisingly common bug I see 
> in a lot of code), and you get convenient accessors for the values stored in 
> the user info.
> 
> And if you don't actually care about any of the user info properties, then 
> the new version is much simpler than the old:
> 
> func handleError(error: Error) {
> switch error {
> case CocoaError.fileNoSuchFileError:
> // handle error
> case URLError.timedOut:
> // handle error
> default:
> // generic handling of other errors
> }
> }
> 
> It's similar to checking the code without the domain in the old style, except 
> now it checks the domain automatically, so you still can't accidentally 
> interpret an error's code in the wrong domain.
> 
> -Kevin Ballard
> 
> On Thu, Aug 4, 2016, at 11:00 AM, Jon Shier via swift-evolution wrote:
>> Doug:
>> Thanks for indulging me so far, I think I’ve almost got it. Prior to this, 
>> using NSError, I could just look at the relevant properties of the error if 
>> I needed to see what type it was. Network errors had different codes from 
>> CloudKit errors, POSIX errors were underlying FileManager errors. A bit 
>> complex due to the undocumented nature of so many of these errors, but I 
>> could ignore any aspect of the error I didn’t care about. Now, however, it 
>> seems I must always care about what types of errors come out of various 
>> methods, as I’ll need to cast to the appropriate types to get useful 
>> information. For example, how would you handle the CloudKit errors I 
>> mentioned before? It seems to me like I would need to, at the point where I 
>> need to extract useful information, do a switch on various casts. First, try 
>> casting to CKError, then to CocoaError (?), and then likely produce a 
>> fatalError if there’s an unexpected type. Or is Error guaranteed to always 
>> cast to something useful? I’ve read the proposal a few times now and it 
>> looks like a lot of casting is going to be required, I’m mostly curious 
>> about the recommended patterns, especially for asynchronous calls that don’t 
>> go through throw/catch. 
>> 
>> 
>> 
>> Jon
>> 
>> 
>>> On Aug 2, 2016, at 5:36 PM, Douglas Gregor >> > wrote:
>>> 
>>> 
 On Aug 2, 2016, at 2:19 PM, Jon Shier > wrote:
 
 Thanks Doug. I missed the rename, as earlier points still referred to 
 ErrorProtocol. In regards to the CloudKit errors, I appreciate the 
 strongly typed CKError, but why not have the methods return that type 
 directly?
>>> 
>>> Generally speaking, Cocoa only uses NSError—not specific subclasses or 
>>> NSError or other error types—because errors can occur at many different 
>>> places in the stack and be propagated up. A CloudKit operation could fail 
>>> because of some problem detected in a different error domain—say, the 
>>> general Cocoa error domain or URLError domain—and that 

Re: [swift-evolution] MemoryLayout for a value

[Xiaodi Wu via swift-evolution]

On Thu, Aug 4, 2016 at 6:02 PM, Dave Abrahams  wrote:

>
> on Thu Aug 04 2016, Dmitri Gribenko  wrote:
>
> > On Wed, Aug 3, 2016 at 7:28 PM, Xiaodi Wu via swift-evolution
> >  wrote:
> >> Could I suggest an alternative? It's conservative in that it mimics the
> >> relationships we had before the proposal was implemented and also
> maintains
> >> the simplicity of the caseless enum:
> >>
> >> ```
> >> extension MemoryLayout {
> >>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
> >>   // etc.
> >> }
> >> ```
> >
> > I like this API.  I think given all the alternatives that we explored,
> > it is better than those.  I also think that it nicely avoids the
> > following issue with the proposed MemoryLayout.of(type(of:
> > someExpression)).size syntax.
> >
> > Imagine that you have a value whose static type differs from the
> > dynamic type.  For example, a protocol existential:
> >
> > protocol P {}
> > extension Int : P {}
> > var x: P = 10
> >
> > The question is, what does MemoryLayout.of(type(of: x)).size compute,
> > size of the existential box, or the size of an Int instance?  The
> > semantics of 'type(of:)' are "return the dynamic type", so the
> > straightforward conclusion is that MemoryLayout.of(type(of: x)).size
> > returns the size of the dynamic type instance, of Int.
> >
> > What actually happens is that 'type(of: x)' returns a dynamic value of
> > 'Int.self', statically typed as 'P.Type'.  So P gets deduced for the
> > generic parameter of MemoryLayout, and MemoryLayout.of(type(of:
> > x)).size returns the size of the protocol box.
> >
> > I think due to this complex interaction, using type(of:) might lead to
> > confusing code, and thus I like Xiaodi's approach better.
> >
> > Dmitri
>
> Okay, I'm convinced; that's what we should do.
>

Proposal and stdlib PRs have both been created.


> --
> -Dave
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[Xiaodi Wu via swift-evolution]

On Fri, Aug 5, 2016 at 2:46 AM, rintaro ishizaki 
wrote:

>
>
> 2016-08-05 16:20 GMT+09:00 Xiaodi Wu :
>
>> On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki 
>> wrote:
>>
>>> > ```
>>> > extension MemoryLayout {
>>> >   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>>> >   // etc.
>>> > }
>>> > ```
>>>
>>> I don't think we can do this while we have:
>>>
>>>   public static var size: Int {
>>>
>>
>> Why not?
>>
>
> My bad. Sorry, never mind.
> I didn't know we can have such overloads (property and func, same
> basename) :O
>

As I mentioned above, it's not only possible but already used in the
standard library. For instance, `first` and `first(where:)` for Collection
types.


> maybe `sizeOf(value _: T) -> Int` ?
>>>
>>>
>>> 2016-08-04 11:28 GMT+09:00 Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org>:
>>>
 On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution <
 swift-evolution@swift.org> wrote:

> > On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> > Having seen the effects in the standard library and in other
> > code, I'm concerned that we may have made a mistake in removing
> > `sizeofValue` et al without providing a replacement.  In the standard
> > library, we ended up adding an underscored API that allows
> >
> >  MemoryLayout._ofInstance(someExpression).size
> >
> > Where someExpression is an autoclosure, and thus not evaluated.  I
> > wanted to bring up the possibility of introducing a replacement as a
> > bufix.
> >
> > I propose that the way to express the above should be:
> >
> >  MemoryLayout.of(type(of: someExpression)).size
> >
> > implementable as:
> >
> >  extension MemoryLayout {
> >@_transparent
> >public
> >static func of(_: T.Type) -> MemoryLayout.Type {
> >  return MemoryLayout.self
> >}
> >  }
> >
> > I think this API would solve the concerns I had about confusability
> that
> > led me to advocate dropping the ability to ask for the size of a
> value.
> > The only way to use it is to pass a type and these two expressions
> have
> > equivalent meaning:
> >
> >MemoryLayout
> >MemoryLayout.of(Int.self)
> >
> > It also has the benefit of isolating the autoclosure magic to
> type(of:).
> >
> > ,[ Aside ]
> > | A slightly cleaner use site is possible with a larger API change:
> > |
> > |   MemoryLayout(type(of: someExpression)).size
> > |
> > | Which would involve changing MemoryLayout from an `enum` to
> > | a `struct` and adding the following:
> > |
> > |   extension MemoryLayout {
> > | public init(_: T.Type) {}
> > |
> > | public var size: Int { return MemoryLayout.size }
> > | public var stride: Int { return MemoryLayout.stride }
> > | public var alignment: Int { return MemoryLayout.alignment }
> > |   }
> > |
> > | However I am concerned that dropping ".of" at the use site is
> worth the
> > | added API complexity.
> > `
> >
> > Thoughts?
> > --
> > -Dave
>
>
> I don't think using "of" is a great burden.
>

 Agreed, but I do think "memory layout of type of my value, size" is a
 mouthful compared to "size of value". Moreover, something doesn't sit right
 with me that MemoryLayout and MemoryLayout.of(T.self) would be one and
 the same thing.

 Could I suggest an alternative? It's conservative in that it mimics the
 relationships we had before the proposal was implemented and also maintains
 the simplicity of the caseless enum:

 ```
 extension MemoryLayout {
   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
   // etc.
 }
 ```


> -- E
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution


>>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[rintaro ishizaki via swift-evolution]

2016-08-05 16:20 GMT+09:00 Xiaodi Wu :

> On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki 
> wrote:
>
>> > ```
>> > extension MemoryLayout {
>> >   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>> >   // etc.
>> > }
>> > ```
>>
>> I don't think we can do this while we have:
>>
>>   public static var size: Int {
>>
>
> Why not?
>

My bad. Sorry, never mind.
I didn't know we can have such overloads (property and func, same basename)
:O



>
> maybe `sizeOf(value _: T) -> Int` ?
>>
>>
>> 2016-08-04 11:28 GMT+09:00 Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org>:
>>
>>> On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 > On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution <
 swift-evolution@swift.org> wrote:
 >
 >
 > Having seen the effects in the standard library and in other
 > code, I'm concerned that we may have made a mistake in removing
 > `sizeofValue` et al without providing a replacement.  In the standard
 > library, we ended up adding an underscored API that allows
 >
 >  MemoryLayout._ofInstance(someExpression).size
 >
 > Where someExpression is an autoclosure, and thus not evaluated.  I
 > wanted to bring up the possibility of introducing a replacement as a
 > bufix.
 >
 > I propose that the way to express the above should be:
 >
 >  MemoryLayout.of(type(of: someExpression)).size
 >
 > implementable as:
 >
 >  extension MemoryLayout {
 >@_transparent
 >public
 >static func of(_: T.Type) -> MemoryLayout.Type {
 >  return MemoryLayout.self
 >}
 >  }
 >
 > I think this API would solve the concerns I had about confusability
 that
 > led me to advocate dropping the ability to ask for the size of a
 value.
 > The only way to use it is to pass a type and these two expressions
 have
 > equivalent meaning:
 >
 >MemoryLayout
 >MemoryLayout.of(Int.self)
 >
 > It also has the benefit of isolating the autoclosure magic to
 type(of:).
 >
 > ,[ Aside ]
 > | A slightly cleaner use site is possible with a larger API change:
 > |
 > |   MemoryLayout(type(of: someExpression)).size
 > |
 > | Which would involve changing MemoryLayout from an `enum` to
 > | a `struct` and adding the following:
 > |
 > |   extension MemoryLayout {
 > | public init(_: T.Type) {}
 > |
 > | public var size: Int { return MemoryLayout.size }
 > | public var stride: Int { return MemoryLayout.stride }
 > | public var alignment: Int { return MemoryLayout.alignment }
 > |   }
 > |
 > | However I am concerned that dropping ".of" at the use site is worth
 the
 > | added API complexity.
 > `
 >
 > Thoughts?
 > --
 > -Dave


 I don't think using "of" is a great burden.

>>>
>>> Agreed, but I do think "memory layout of type of my value, size" is a
>>> mouthful compared to "size of value". Moreover, something doesn't sit right
>>> with me that MemoryLayout and MemoryLayout.of(T.self) would be one and
>>> the same thing.
>>>
>>> Could I suggest an alternative? It's conservative in that it mimics the
>>> relationships we had before the proposal was implemented and also maintains
>>> the simplicity of the caseless enum:
>>>
>>> ```
>>> extension MemoryLayout {
>>>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>>>   // etc.
>>> }
>>> ```
>>>
>>>
 -- E

 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution

>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[Xiaodi Wu via swift-evolution]

On Fri, Aug 5, 2016 at 2:06 AM, rintaro ishizaki 
wrote:

> > ```
> > extension MemoryLayout {
> >   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
> >   // etc.
> > }
> > ```
>
> I don't think we can do this while we have:
>
>   public static var size: Int {
>

Why not?

maybe `sizeOf(value _: T) -> Int` ?
>
>
> 2016-08-04 11:28 GMT+09:00 Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org>:
>
>> On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> > On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> >
>>> > Having seen the effects in the standard library and in other
>>> > code, I'm concerned that we may have made a mistake in removing
>>> > `sizeofValue` et al without providing a replacement.  In the standard
>>> > library, we ended up adding an underscored API that allows
>>> >
>>> >  MemoryLayout._ofInstance(someExpression).size
>>> >
>>> > Where someExpression is an autoclosure, and thus not evaluated.  I
>>> > wanted to bring up the possibility of introducing a replacement as a
>>> > bufix.
>>> >
>>> > I propose that the way to express the above should be:
>>> >
>>> >  MemoryLayout.of(type(of: someExpression)).size
>>> >
>>> > implementable as:
>>> >
>>> >  extension MemoryLayout {
>>> >@_transparent
>>> >public
>>> >static func of(_: T.Type) -> MemoryLayout.Type {
>>> >  return MemoryLayout.self
>>> >}
>>> >  }
>>> >
>>> > I think this API would solve the concerns I had about confusability
>>> that
>>> > led me to advocate dropping the ability to ask for the size of a value.
>>> > The only way to use it is to pass a type and these two expressions have
>>> > equivalent meaning:
>>> >
>>> >MemoryLayout
>>> >MemoryLayout.of(Int.self)
>>> >
>>> > It also has the benefit of isolating the autoclosure magic to
>>> type(of:).
>>> >
>>> > ,[ Aside ]
>>> > | A slightly cleaner use site is possible with a larger API change:
>>> > |
>>> > |   MemoryLayout(type(of: someExpression)).size
>>> > |
>>> > | Which would involve changing MemoryLayout from an `enum` to
>>> > | a `struct` and adding the following:
>>> > |
>>> > |   extension MemoryLayout {
>>> > | public init(_: T.Type) {}
>>> > |
>>> > | public var size: Int { return MemoryLayout.size }
>>> > | public var stride: Int { return MemoryLayout.stride }
>>> > | public var alignment: Int { return MemoryLayout.alignment }
>>> > |   }
>>> > |
>>> > | However I am concerned that dropping ".of" at the use site is worth
>>> the
>>> > | added API complexity.
>>> > `
>>> >
>>> > Thoughts?
>>> > --
>>> > -Dave
>>>
>>>
>>> I don't think using "of" is a great burden.
>>>
>>
>> Agreed, but I do think "memory layout of type of my value, size" is a
>> mouthful compared to "size of value". Moreover, something doesn't sit right
>> with me that MemoryLayout and MemoryLayout.of(T.self) would be one and
>> the same thing.
>>
>> Could I suggest an alternative? It's conservative in that it mimics the
>> relationships we had before the proposal was implemented and also maintains
>> the simplicity of the caseless enum:
>>
>> ```
>> extension MemoryLayout {
>>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>>   // etc.
>> }
>> ```
>>
>>
>>> -- E
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

[Raphael Sebbe via swift-evolution]

thank you Ankit for that information.

Do you mean a single (SwiftPM) repository could handle the 5 static libs I
was mentioning in my first mail, with apps linking selectively with those,
as opposed to entire module/product? That'd be great.

Also, what about the state of integration in Xcode, can those setup
(SwiftPM packages) work somehow for development (including debugging, code
completion, etc), or is it something mostly distinct for now?

Thanks.

Raphael

On Fri, Aug 5, 2016 at 6:32 AM Ankit Agarwal  wrote:

> Swift, with its extension concept, is very well suited to modular
>> development like this. We'd like to have a better option than frameworks to
>> build reusable libraries. It's not an ABI thing, we really don't care about
>> that, we use libs just to organize code, building them as a part of the
>> app, and *not* to provide precompiled libraries to some other developers.
>> Swift package manager does not work well within Xcode either at this time,
>> and has a number of constraints we don't want (like having a separate git
>> repo for each static lib -> that's not practical at all if you just have 1
>> or 2 files in that lib).
>>
>
> You don't need to create one repo for each static library. A SwiftPM
> package consists of Modules. You can create any number of products
> consisting of one or more modules using the Product API in manifest file.
> for eg:
>
> products += [Product(name: "StaticLibA", type: .Library(.Static), modules:
> "Foo"), Product(name: "StaticLibB", type: .Library(.Static), modules:
> "Foo", "Bar")]
>
> --
> Ankit
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] MemoryLayout for a value

[rintaro ishizaki via swift-evolution]

> ```
> extension MemoryLayout {
>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>   // etc.
> }
> ```

I don't think we can do this while we have:

  public static var size: Int {

maybe `sizeOf(value _: T) -> Int` ?


2016-08-04 11:28 GMT+09:00 Xiaodi Wu via swift-evolution <
swift-evolution@swift.org>:

> On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> > Having seen the effects in the standard library and in other
>> > code, I'm concerned that we may have made a mistake in removing
>> > `sizeofValue` et al without providing a replacement.  In the standard
>> > library, we ended up adding an underscored API that allows
>> >
>> >  MemoryLayout._ofInstance(someExpression).size
>> >
>> > Where someExpression is an autoclosure, and thus not evaluated.  I
>> > wanted to bring up the possibility of introducing a replacement as a
>> > bufix.
>> >
>> > I propose that the way to express the above should be:
>> >
>> >  MemoryLayout.of(type(of: someExpression)).size
>> >
>> > implementable as:
>> >
>> >  extension MemoryLayout {
>> >@_transparent
>> >public
>> >static func of(_: T.Type) -> MemoryLayout.Type {
>> >  return MemoryLayout.self
>> >}
>> >  }
>> >
>> > I think this API would solve the concerns I had about confusability that
>> > led me to advocate dropping the ability to ask for the size of a value.
>> > The only way to use it is to pass a type and these two expressions have
>> > equivalent meaning:
>> >
>> >MemoryLayout
>> >MemoryLayout.of(Int.self)
>> >
>> > It also has the benefit of isolating the autoclosure magic to type(of:).
>> >
>> > ,[ Aside ]
>> > | A slightly cleaner use site is possible with a larger API change:
>> > |
>> > |   MemoryLayout(type(of: someExpression)).size
>> > |
>> > | Which would involve changing MemoryLayout from an `enum` to
>> > | a `struct` and adding the following:
>> > |
>> > |   extension MemoryLayout {
>> > | public init(_: T.Type) {}
>> > |
>> > | public var size: Int { return MemoryLayout.size }
>> > | public var stride: Int { return MemoryLayout.stride }
>> > | public var alignment: Int { return MemoryLayout.alignment }
>> > |   }
>> > |
>> > | However I am concerned that dropping ".of" at the use site is worth
>> the
>> > | added API complexity.
>> > `
>> >
>> > Thoughts?
>> > --
>> > -Dave
>>
>>
>> I don't think using "of" is a great burden.
>>
>
> Agreed, but I do think "memory layout of type of my value, size" is a
> mouthful compared to "size of value". Moreover, something doesn't sit right
> with me that MemoryLayout and MemoryLayout.of(T.self) would be one and
> the same thing.
>
> Could I suggest an alternative? It's conservative in that it mimics the
> relationships we had before the proposal was implemented and also maintains
> the simplicity of the caseless enum:
>
> ```
> extension MemoryLayout {
>   static func size(ofValue _: T) -> Int { return MemoryLayout.size }
>   // etc.
> }
> ```
>
>
>> -- E
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution