Re: [swift-evolution] [Request for Feedback] Providing defaults for reading and writing.

It seems like it would be cleaner to extend CodingKey. There might be a more general way of doing this than just requiring a Dictionary, but it seems to work. protocol DefaultingCodingKey: CodingKey, Hashable { static var defaults: [Self: Any] { get } } // Implementing the other overrides

[swift-evolution] [Pitch] Array full proposal

Spent the past week coming up with a full proposal for fixed-size arrays. I wrote it mainly from the bottom upwards. There may be some inconsistencies. And I'm not entirely sure what "structural sub-typing" means, or if it's appropriate for arrays.

Re: [swift-evolution] JIT compilation for server-side Swift

Hi, First of all let me welcome the project. My knowledge to JITs is little but I come from Java world where JITs takes a major role. Let me share my initial thoughts on this: 1. Runtime code optimization. Java JIT does this pretty much well. But how can a Swift code already optimized compile

Re: [swift-evolution] [Request for Feedback] Providing defaults for reading and writing.

> On Jul 10, 2017, at 5:16 PM, William Shipley via swift-evolution > wrote: > > (Note the horrible hack on KeyedEncodingContainer where I had to special-case > arrays of s, I guess because the compiler doesn’t know an array of > s is Equatable itself?) Correct.

Re: [swift-evolution] [Pitch] Guard/Catch

> On Jul 10, 2017, at 1:51 AM, David Hart via swift-evolution > wrote: > > I know we can’t do much about it now, but if optional binding had used the > same syntax as it does in pattern matching, we wouldn’t be having this > discussion: > > guard let x = try

[swift-evolution] [Request for Feedback] Providing defaults for reading and writing.

Automatic substitution / removal of default values is very useful when reading or writing a file, respectively, and should be supported by the family of protocols and objects: • When reading, swapping in a default value for missing or corrupted values makes it so hand-created or

Re: [swift-evolution] JIT compilation for server-side Swift

On Mon, Jul 10, 2017 at 1:53 PM, Michael Ilseman wrote: > > On Jul 10, 2017, at 9:40 AM, Younes Manton via swift-evolution < > swift-evolution@swift.org> wrote: > > Having said that, it is with the static side in mind that I'm writing this > email. Despite the prototype JIT

Re: [swift-evolution] JIT compilation for server-side Swift

On Mon, Jul 10, 2017 at 1:31 PM, Benjamin Spratling wrote: > I'm aware that Java re-compiles sections to make incremental performance > improvements based on a statistical analysis of usage. I'm not familiar > enough with other uses of JIT on the backend to know what

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

on Sun Jul 09 2017, Brent Royal-Gordon wrote: > But however we achieve it, I think a spoonful of > syntactic sugar would help the medicine go down. Let me be clear: syntactic sugar matters. Otherwise, we'd all be programming directly in LLVM IR. It's just a question of what you have to pay

Re: [swift-evolution] JIT compilation for server-side Swift

> On Jul 10, 2017, at 9:40 AM, Younes Manton via swift-evolution > wrote: > > Hi, > > Last year a small group of developers from the IBM Runtimes compiler team > undertook a project to explore JIT compilation for Swift, primarily aimed at > server-side Swift. The

Re: [swift-evolution] JIT compilation for server-side Swift

No, this is completely unrelated. This is about runtime optimization of already-running swift programs. > On Jul 10, 2017, at 10:40 AM, Jacob Williams via swift-evolution > wrote: > > Pardon my lack of knowledge about JIT compilation, but does this open the >

Re: [swift-evolution] JIT compilation for server-side Swift

Pardon my lack of knowledge about JIT compilation, but does this open the realm of possibilities to a client-side swift that would allow web developers to write swift code rather than javascript? > On Jul 10, 2017, at 10:40 AM, Younes Manton via swift-evolution >

[swift-evolution] JIT compilation for server-side Swift

Hi, Last year a small group of developers from the IBM Runtimes compiler team undertook a project to explore JIT compilation for Swift, primarily aimed at server-side Swift. The compilation model we settled on was a hybrid approach that combined static compilation via swiftc with dynamic

Re: [swift-evolution] [Pitch] Guard/Catch

I don't think that "guard let x? = ..." would be syntactically correct, AFAIK for matching the pattern "let x? =", as for any other pattern, you need to use "case", in fact the following is perfectly valid: guard case let x? = doSomething() else { // handle when nil } I think that "guard

Re: [swift-evolution] [Pre-pitch] Allowing enums inside protocols?

Wouldn’t the following work just as well for providing a namespace? struct Foozle { enum Errors: Error { case malformedFoozle case tooManyFoozles } } ~Akshay > On Jul 8, 2017, at 17:24, Jonathan Hull via swift-evolution > wrote: > > I

[swift-evolution] [Pitch] Guard/Catch

One of the reasons I like this proposal is at a higher level we are checking for errors and have the ability to exit early if there is an error, I think this aligns well with what `guard` represents, at least to me. Using `try?` effectively ignores the error so if we want convenience we have to

[swift-evolution] [Proposal] Refine SE-0015 (Tuple Comparison Operators) to include empty case

I propose adding support for using comparison operators on the empty tuple. This is an extension of SE-0015.

[swift-evolution] Better handling of enum cases with associated values

Hi, I wanted to propose a better handling of enum cases with associated value (somewhat) detailed proposal is here https://github.com/zats/swift-evolution/blob/master/proposals/0181-better-handling-of-enum-cases-with-associated-values.md

Re: [swift-evolution] [Proposal] Introduces endianness specific type

Thanks, but we can implement Codable for BEInteger and LEInteger types. public struct BEInteger : FixedWidthInteger { public var bitPattern: BitPattern public init(bitPattern: BitPattern) public var bigEndian: BEInteger { get } public var littleEndian: LEInteger { get

Re: [swift-evolution] [Pitch] Guard/Catch

> On 10 Jul 2017, at 09:45, Elviro Rocca via swift-evolution > wrote: > > This is not a sugar proposal, in the same way as "guard" is not syntactic > sugar, because it requires exiting the scope on the else branch, adding > expressive power and safety to the call:

Re: [swift-evolution] [Pitch] Guard/Catch

This is not a sugar proposal, in the same way as "guard" is not syntactic sugar, because it requires exiting the scope on the else branch, adding expressive power and safety to the call: also, the sugary part is pretty important because it avoids nested parentheses and very clearly states that

Re: [swift-evolution] [Pitch] Scoped @available

2017-07-10 14:05 GMT+09:00 Xiaodi Wu : > This would be very useful, but the spelling needs dramatic improvement. > > "Available unavailable" is already challenging to read, but at least it is > learnable with time. The example where "@available(*, deprecated, access: >