Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

> On Nov 3, 2017, at 9:16 PM, Swift via swift-evolution > wrote: > > It’s possible I missed something, but my attempt at implementing it only > touched 3 files. One was the actual implementation, another was adapting the > diagnostics messages, and the third was

Re: [swift-evolution] Abstract methods

> On Nov 2, 2017, at 8:29 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 2, 2017, at 1:57 PM, Taylor Swift via swift-evolution >> > wrote: >> >> Swift architectures use much less

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

> On Nov 3, 2017, at 9:59 PM, Chris Lattner wrote: > > >> On Nov 3, 2017, at 8:40 AM, Dave DeLong via swift-evolution >> wrote: >> >> That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap. >> >> Chris has mentioned in

Re: [swift-evolution] Adding Result to the Standard Library

> On Nov 3, 2017, at 1:43 PM, Alex Lynch via swift-evolution > wrote: > > Where are the guiding documents for swift's concurrency support? I have an > unrelated idea for the language that I think would be a sizable win for > concurrency. (I won't cross post it

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

> On Nov 3, 2017, at 8:40 AM, Dave DeLong via swift-evolution > wrote: > > That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap. > > Chris has mentioned in interviews that such a system is "a big feature that’s > open-ended and requires a

Re: [swift-evolution] continuations - "extensions on steroids" idea

On 3 November 2017 at 21:36, Adam Kemp wrote: > > Your ledger idea might theoretically prevent some of those bad things from > happening, but at the expense of making the whole thing unusable for this > use case. That’s not a good trade off. > well, this particular one is

Re: [swift-evolution] continuations - "extensions on steroids" idea

> On Nov 3, 2017, at 11:45 AM, Mike Kluev wrote: > > On 3 November 2017 at 18:08, Adam Kemp > wrote: > > 1. You end up with a whole section of type aliases at the top of the file, > > i'm putting those in a separate

Re: [swift-evolution] f suffix for float32 literals, h suffix for float16 literals

On Fri, Nov 3, 2017 at 1:26 PM, nick ralabate via swift-evolution < swift-evolution@swift.org> wrote: > I think it would be helpful for graphics programmers to specify vertex > data inline without surrounding every value with Float(4.0). > Two pointers: a. You never actually want to write

Re: [swift-evolution] Adding Result to the Standard Library

Where are the guiding documents for swift's concurrency support? I have an unrelated idea for the language that I think would be a sizable win for concurrency. (I won't cross post it here.) RE Error syntax: Syntactic sugar that makes it easier to ignore errors is a miss-step, I think. Errors

Re: [swift-evolution] f suffix for float32 literals, h suffix for float16 literals

> On Nov 3, 2017, at 3:33 PM, Kelvin Ma wrote: > > > > On Fri, Nov 3, 2017 at 2:05 PM, Steve Canon via swift-evolution > > wrote: > If/when 16b floats were added to the standard lib, you would just write: >

Re: [swift-evolution] f suffix for float32 literals, h suffix for float16 literals

On Fri, Nov 3, 2017 at 2:05 PM, Steve Canon via swift-evolution < swift-evolution@swift.org> wrote: > If/when 16b floats were added to the standard lib, you would just write: > > let vertexData: [Float16] = [ 1, 0, 0.5, 1 ] > > I should note that something like vertex coordinates is usually

Re: [swift-evolution] f suffix for float32 literals, h suffix for float16 literals

If/when 16b floats were added to the standard lib, you would just write: let vertexData: [Float16] = [ 1, 0, 0.5, 1 ] I should note that something like vertex coordinates is usually better modeled with a more specific type than [Float], like SCNVector4 or simd.float4 or your own type,

Re: [swift-evolution] f suffix for float32 literals, h suffix for float16 literals

You can write this for the first thing that you want: let vertexData: [Float] = [1.0, 0.0, 0.5, 1.0] I don't know enough about 16-bit floats to comment on those. On Fri, Nov 3, 2017 at 11:26 AM nick ralabate via swift-evolution < swift-evolution@swift.org> wrote: > I think it would be

Re: [swift-evolution] continuations - "extensions on steroids" idea

On 3 November 2017 at 18:08, Adam Kemp wrote: > > 1. You end up with a whole section of type aliases at the top of the file, > i'm putting those in a separate Platform.swift file > and as you read the file it’s hard to understand what those types actually > represent. >

[swift-evolution] [draft] Make Standard Library Index Types Hashable

Hello! I’d like to propose adding Hashable conformance to the standard library’s index types, making subscripts in key path expressions more useful with the standard library’s collections. Note that this will not affect the requirements for Collection’s associated Index type, only concrete

[swift-evolution] f suffix for float32 literals, h suffix for float16 literals

I think it would be helpful for graphics programmers to specify vertex data inline without surrounding every value with Float(4.0). Something like this: let vertexData = [ 1.0f, 0.0f, 0.5f, 1.0f ] Also, it would be great if Swift had a type for half-floats to match the iPhone GPU: let

Re: [swift-evolution] continuations - "extensions on steroids" idea

> On Nov 3, 2017, at 10:55 AM, Mike Kluev wrote: > > On 3 November 2017 at 17:23, Adam Kemp > wrote: > > > When you actually try to use that technique in a fuller example it becomes > impractical. I know because some

Re: [swift-evolution] continuations - "extensions on steroids" idea

On 3 November 2017 at 17:23, Adam Kemp wrote: > > > When you actually try to use that technique in a fuller example it becomes > impractical. I know because some people working on the same code base tried > that, and it was much worse. > please provide more details on this.

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

The call stack could certainly be a worthwhile thing to capture in an operator implementation. The #file and #line would tell you which usage of the operator you’re using, and the callStackSymbols would tell you how you got there. You’d want them both, however, if you used the same custom

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

on Fri, 3 Nov 2017 09:40:35 -0600 Dave DeLong wrote: > That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap. > > Chris has mentioned in interviews that such a system is "a big feature that’s open-ended and requires a huge design process” which makes

[swift-evolution] Zero-copy String buffer access

One of Swift’s major advantages as a language is the ease of bridging from Swift code to C. This ease makes it possible to utilise the vast body of existing code to bootstrap projects, rather than reinventing the world in Swift every time we have a problem. The String type in Swift has some

Re: [swift-evolution] continuations - "extensions on steroids" idea

> On Nov 3, 2017, at 10:05 AM, Mike Kluev wrote: > > On 3 November 2017 at 16:42, Adam Kemp > wrote: > > If that’s the case then this wouldn’t solve one of the major use cases I > listed for this: splitting up

Re: [swift-evolution] continuations - "extensions on steroids" idea

On 3 November 2017 at 16:42, Adam Kemp wrote: > > If that’s the case then this wouldn’t solve one of the major use cases I > listed for this: splitting up cross-platform classes into platform-specific > files. The idea is that each target contains a different subset of the >

[swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

At Swift Summit, we discussed with Joe and Jordan about opening up the Encoder/Decoder classes in order to make the work of an encoder designer easier. As I was working on an API project, I found myself into the situation of needing to tweak so slightly the encoding strategy this required a

Re: [swift-evolution] continuations - "extensions on steroids" idea

> On Nov 3, 2017, at 5:17 AM, Mike Kluev wrote: > > On 3 November 2017 at 03:05, Adam Kemp > wrote: > > > Would it be an error to have an entry in the “ledger” but not a corresponding > implementation? > > definitely

Re: [swift-evolution] Adding Result to the Standard Library

Except | is commutative, so you would except Int | Error to be equivalent to Error | Int, which isn't the semantic of the Result type. On Fri, Nov 3, 2017 at 4:04 PM, Elia Cereda wrote: > I'd say that this syntax would be even more coherent with protocol > composition,

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap. Chris has mentioned in interviews that such a system is "a big feature that’s open-ended and requires a huge design process” which makes off-the-table for Swift 5, and (I’m guessing) unlikely for Swift 6 too.

Re: [swift-evolution] Abstract methods

(Though calling "super" and Implementing non-public methods would round out "protocol as abstract class" functionality.) -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesolutionspace.blogspot.com/ > On

Re: [swift-evolution] Abstract methods

If protocols can (1) store data (2) implement methods (3) force "subclasses" to implement methods, then I'm ok that it isn't spelled "abstract". And yes, I know 2 and 3 done. -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? *

Re: [swift-evolution] Adding Result to the Standard Library

I'd say that this syntax would be even more coherent with protocol composition, given that x is effectively an Int or an Error: > var x: Int | Error But aside from the specific syntax, I'm pretty sure it isn't the first time this request comes up and there were good reasons for rejecting it.

Re: [swift-evolution] Adding Result to the Standard Library

If my memory does not fail, there has also been a discussion about adding a "payload" to the optional types that fit into that context. Something like: //Current enum Optional{ case Some(T) case None } // Adding enum Optional{ case Some(T) case None(Error) //Maybe adding support

Re: [swift-evolution] continuations - "extensions on steroids" idea

On 3 November 2017 at 02:52, Noah Desch wrote: > > I’m +1 on the ledger and partial classes in general. I think extensions > serving the dual purpose of extending other module’s classes, as well as an > organizational tool for in-module classes has resulted in some bad

Re: [swift-evolution] continuations - "extensions on steroids" idea

On 3 November 2017 at 03:05, Adam Kemp wrote: > > > Would it be an error to have an entry in the “ledger” but not a > corresponding implementation? > definitely so. and vice versa. Mike ___ swift-evolution mailing list

Re: [swift-evolution] Adding Result to the Standard Library

Actually i'd even prefer : var x: Int ?? Error the spaces makes it more readable, it looks like what you'd do with the ?? operator already, and it seems coherent with the syntax for protocol composition. On Fri, Nov 3, 2017 at 12:12 PM, Benjamin G wrote: > Just

Re: [swift-evolution] Adding Result to the Standard Library

To be fair, I would want to see the outcome of the `typed throws` discussion first before moving the discussion about `Result` forward.  Am 3. November 2017 um 04:41:32, Chris Lattner via swift-evolution (swift-evolution@swift.org) schrieb: On Nov 2, 2017, at 11:08 AM, Jon Shier via

Re: [swift-evolution] Adding Result to the Standard Library

Just an idea for the type declaration : Why not use the same ? as Optional, but with the type of the error behind : Such as var x: Int?Error Optional Int (Int?) would be seen a special case of Result where the error type is nil. The advantage of this syntax is that it would let us specify the

Re: [swift-evolution] Adding Result to the Standard Library

I'm also in favor of providing the ability to specify the type of the error for the result. It provides self-documenting and type safety advantages over the generic Error that really makes the type much more useful. The ideal would be to have the two possible syntax (Result and Result) , but

Re: [swift-evolution] Adding Result to the Standard Library

Right, to me there is not a lot of value in adding Result as it exists in AlamoFire. We will (eventually) use the Swift Package Manager for things like this. The value would be in integrating it like Optionals. e.g. (using a strawman symbol) var x: Int‽ = 5 var y: Int‽ = anErrorValue