Re: [swift-evolution] MemoryLayout for a value

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. >

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

> 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: >>> >>>

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

> 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

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

> 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

Re: [swift-evolution] MemoryLayout for a value

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

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

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 >>>

Re: [swift-evolution] MemoryLayout for a value

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

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

> 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

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

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

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

> 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.

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

> 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

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

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,

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

> 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

[swift-evolution] A unified error handling mechanism?

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:

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

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

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

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

Re: [swift-evolution] [META] Gmane and 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

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

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

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

> 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

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

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

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

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

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

> 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

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

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

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

> 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

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

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,

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

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

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

> 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.

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

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 <

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

> 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

Re: [swift-evolution] MemoryLayout for a value

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

Re: [swift-evolution] MemoryLayout for a value

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

Re: [swift-evolution] MemoryLayout for a value

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

Re: [swift-evolution] MemoryLayout for a value

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

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

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,

Re: [swift-evolution] MemoryLayout for a value

> ``` > 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