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

[Brent Royal-Gordon via swift-evolution]

> On Nov 2, 2017, at 7:05 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Firstly, because for the proposed use case it's not a "default" parameter in 
> that it's not overridable: you can't actually pass another argument.


Sure you can. Remember, you can call an operator with function-call syntax:

(+)(1, 2)

We could allow you to specify the non-default parameters when you need to using 
this syntax:

// Normal use:
value !! MyError.missingValue

// With defaulted parameters changed:
(!!)(value, MyError.missingValue, file: someFile, line: someLine)

We could also—as part of a separate proposal, perhaps in a future version of 
Swift—explore a more elegant syntax for adding options to operator calls. This 
could be useful for things like string comparisons where you need to decide 
whether a comparison should be locale-aware, case-sensitive, etc.

// Strawman syntax of possible future expansion:
value !! MyError.missingValue #(file: someFile, line: someLine)

-- 
Brent Royal-Gordon
Architechies

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

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

[Slava Pestov via swift-evolution]

> 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 huge design process” which makes off-the-table for 
> Swift 5, and (I’m guessing) unlikely for Swift 6 too.
> 
> Personally I’d like to be able to better debug my apps in Swift 4.1 rather 
> than waiting another 2 or 3 years for a magical macro system to somehow solve 
> this.

Heh. I sort of feel that adding procedural macros to a language with a complex 
syntax and semantics like Swift doesn’t make much sense at all. I would be 
pretty strongly opposed to any macro system proposal unless a compelling case 
could be made that it would improve implementation quality by significantly 
simplifying the code (for example, by moving parts of the type checker into the 
standard library).

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

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

[Slava Pestov via swift-evolution]

> 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 the tests. 
> 
> I’m still new to building swift myself, but the tests all passed...
> 
> https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697
>  
> 
If you’re looking to move forward with this proposal, you should also add a 
SILGen test, and an executable test too.

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

Re: [swift-evolution] Abstract methods

[Slava Pestov via swift-evolution]

> 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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Swift architectures use much less inheritance (and class types) in general 
>> than equivalent c++ architectures. personally i have never been in a 
>> situation where i didn’t need a pure abstract method that was better 
>> declared as a protocol requirement.
> 
> 
> I think we should beef up protocols a little bit so that they can serve the 
> role of abstract classes. That would make for a nice, clean separation: 
> anything abstract is a protocol, while anything concrete is a class (or 
> struct or enum).
> 
> What would protocols need in order to support everything abstract classes can 
> do? First, we'd probably need to extend class constraints to allow a protocol 
> to require you to subclass a given base class:
> 
>   // Hypothetical replacement for UIControl.
>   protocol UIControl: UIView {
>   func sendAction(_ action: Selector, to target: Any?, for event: 
> UIEvent)
>   }

This is planned, and in fact was part of the “subclass existentials” proposal 
that was otherwise implemented in Swift 4. The absence of this feature should 
be considered a bug, and something I’d like to fix eventually.

> Maybe allow them to declare automatically-added storage, perhaps even private 
> to the protocol:

I’m not sure this really fits with the conceptual model of what a protocol is. 
Protocols define requirements, they don’t “add” things to the conforming type. 
It seems that allowing protocols to declare stored properties would bring many 
of the complications of multiple inheritance from an implementation standpoint. 
Also how would retroactive conformance work? Would you just be able to change 
the size of any public type in any other framework? This would have major 
implications for code generation and the optimizer.

In general I’m not convinced this is a useful feature.

> Probably something like `super` for when you want to override a default 
> implementation but still call it:

This is a good idea. I think it would be pretty straightforward to implement, 
and it’s something that keeps coming up. We haven’t come up with a nice 
unambiguous syntax for it yet.

Slava

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

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

[Swift via swift-evolution]

> 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 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.
>> 
>> Personally I’d like to be able to better debug my apps in Swift 4.1 rather 
>> than waiting another 2 or 3 years for a magical macro system to somehow 
>> solve this.
> 
> You’re assuming somehow that this is an “easy” feature.  I haven’t seen a 
> concrete proposal, but I don’t see how adding hidden options to operators 
> compose into the existing system.
> 
> -Chris

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

I’m still new to building swift myself, but the tests all passed...

https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697

As for a formal proposal, I’ll hopefully have some time this weekend to put 
that together. 

Can you expound some more on what you mean by hidden options to operators not 
composing into the existing system? I’m not sure I follow. 

Dave

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

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

[Chris Lattner via swift-evolution]

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

These are MHOs, but if you want to talk concurrency, you should start a new 
thread:

https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 


-Chris

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

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

[Chris Lattner via swift-evolution]

> 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 huge design process” which makes off-the-table for 
> Swift 5, and (I’m guessing) unlikely for Swift 6 too.
> 
> Personally I’d like to be able to better debug my apps in Swift 4.1 rather 
> than waiting another 2 or 3 years for a magical macro system to somehow solve 
> this.

You’re assuming somehow that this is an “easy” feature.  I haven’t seen a 
concrete proposal, but I don’t see how adding hidden options to operators 
compose into the existing system.

-Chris

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

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

[Mike Kluev via swift-evolution]

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 not impossible with ledger:

class View: UIView {
   part Feature1// *** default
   optional part Feature2   // *** the behaviour you describing
}

or even this (if majority agrees this is a better default):

class View: UIView {
   required part Feature1// *** opt-in
   part Feature2   // *** optional, the behaviour you describing
}

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

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

[Adam Kemp via swift-evolution]

> 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 Platform.swift file
>  
> and as you read the file it’s hard to understand what those types actually 
> represent.
> 
> in the example above "View" - a very similar concept between macOS and 
> iOS/tvOS/watchOS.
> in case of doubts - command click is always at the finger tips.
>  
> Which methods are you actually allowed to use? What should code completion 
> show you? 
> 
> autocomplete shows the relevant methods on each platform correctly.
> 
> 2. The type alias is only useful when the naming of the methods/properties is 
> identical and the sequence of calls you have to make is identical, which very 
> often isn’t the case. You end up needing conditional compilation anyway for 
> cases where you only need to make a call on one platform, or where the method 
> you have to call is named slightly different or takes different arguments.
> 
> if the differences are minute i'm creating my own extension methods to make 
> the difference non existent.
> 
> example: layer is optional on OSX and non optional on iOS. the difference is 
> minute and i can make this difference non existent, e.g. by:
> 
> extension UIView {
> var viewLayer: CALayer? {
> return layer
> }
> }
> 
> and a similar thing on OSX, and afterwards i have single API on both 
> platforms with no differences.
> 
> You end up needing conditional compilation anyway for cases where you only 
> need to make a call on one platform, or where the method you have to call is 
> named slightly different or takes different arguments. 
>  
>  
> i rarely have to use conditional compilation and even when have to do so i 
> normally hide it inside the relevant "utility" extensions, from then on i 
> don't see anything "conditional" within the normal app sources.
>  
> Out of the strategies I’ve seen used for cross-platform code this one was the 
> most frustrating to work with in my experience.
> 
> quite the contrary to me - the best possible experience with such an approach 
> (during many years of experience ftm)

All I can say is, again, I’ve worked with code that plays these tricks, and I 
found it much harder to deal with than the code that used partial classes. 
You’re using all the tricks you can to make it work, but in my experience those 
tricks add up to a code base that is harder to work with and harder to 
understand and more brittle than the alternative approach I described. The 
tricks are part of what makes it confusing. At the risk of sounding 
presumptuous, I think if you could actually try the other approach (i.e., if we 
actually had partial classes that work like in C#) you would likely agree. 
Unfortunately it’s hard to do that comparison when you haven’t tried both 
approaches in real world situations.

>  
>> My argument is that there should be no ledger in the first place. IMO you 
>> haven’t made the case for that requirement.
> 
> the real-world example would be:
> 
> case 1. you have a single page of paper on hands saying: "partial contract A. 
> continued elsewhere. Blah, blah". you look around and within a multitude of 
> papers on the table you managed to find another sheet of paper with "partial 
> contract A. continued elsewhere. Blah, blah". in order to find the whole 
> thing you will have to look in all papers on your table, then in the shelve 
> and then in the whole building (module boundaries)

This is not how it works in practice. In practice the files are right next to 
each other with similar names. It would be more like having “to be continued” 
at the end of a book sitting right next to another book with the same name plus 
“Volume 2”. I think you would know where to look.

If you work with people who can’t follow conventions and would try to extend 
partial classes from random places then I’m sorry. :)

You may notice that this has echoes to our earlier conversation where I was on 
the other side of a very similar disagreement about extensions. I argued that 
extensions would lead to confusion because they can be thrown anywhere, and 
someone pointed out that there are file naming conventions for that. I think 
this is different because extensions are very often included in random files 
where they are most convenient. They have a different meaning and a different 
use case that I think encourages their use in files that are not named after 
the class they’re extending.

Partial classes aren’t intended to be used that way so it really never makes 
sense to have a partial class implementation in a file that is not dedicated 
specifically to that partial class implementation. That would raise red flags 
during code reviews. It’s a very simple rule to follow: if you see “partial 
class Foo” then the file name better start with “Foo”.

If I thought it made se

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

[Xiaodi Wu via swift-evolution]

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 `Float(4.0)`, which casts a
`FloatLiteralType aka Double` with value `4.0` to `Float`. You want `4 as
Float`.  This is an issue which has come up several times before on this
list.

b. You don't need to do this for every value in an array. You only need to
annotate one; probably the first one for your readers' sanity:

```
let vertexData = [1 as Float, 0, 0.5, 1]
```

Alternatively, you can use explicit type annotations as shown by others.


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 vertexData = [ 1.0h, 0.0h, 0.5h, 1.0h]
>
>
> Thanks!
>
> ___
> 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] Adding Result to the Standard Library

[Alex Lynch via swift-evolution]

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 differ from optionals in how you handle the un-happy path.

With optionals: if the data isn't there you either O1) abort, or O2) follow
an alternative, acceptable path.
With errors: if the data isn't there you either E1) log-and-abort or E2)
present the error, either directly or via propagation.

That is to say – with errors the programmer has a greater responsibly to
honor the _content_ of the error, not just its presence.
To merely ignore the error (which is possible to do with the `try?` syntax,
is almost always an anti-pattern.

TL;DR. Error handling bares a greater responsibly than optional handling.
Responsible code is safer code.

I support the introduction of a `Result` type into the language (perhaps as
a core-lib like Dispatch), because it follows the principle of
responsibility.

RE Async syntax:
In like manner, I don't think it's a good idea to make the _call site_ of
asynchronous functions the same as the call site of synchronous functions.
If this were the case it would be very easy to confuse asynchronous
functions as synchronous and accidentally make your own function
asynchronous.

If there is any change to the language to add syntactic wrappers around
async methods, I think they should be lexically demarcated just like
throwing functions are. For example:

```
try someThrowingFunction()

async someAsyncFunction() // the natural call signature here would have
been someAsyncFunction(callback: {} )
```

Just like `try` is not for the compiler, but is a flag for the programmer
to pay attention, so – I think – there should be a similar flag that causes
the programmer to pay attention to async functions.

EPILOG :
But the above example actually takes us directly into the topic of
promises/futures. (What is _actually_ returned if we call an asynchronous
function with synchronous syntax?)
I have lot of thoughts on promises, safely-implemented async functions, and
the general practice of concurrent programming in swift. But maybe this
isn't the best thread for that broader discussion. ???

Thoughts?


On Fri, Nov 3, 2017 at 12:16 PM, Benjamin G via swift-evolution <
swift-evolution@swift.org> wrote:

> 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, 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.
>>
>> Elia Cereda
>>
>> Il giorno 03 nov 2017, alle ore 13:10, Benjamin G via swift-evolution <
>> swift-evolution@swift.org> ha scritto:
>>
>> 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 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 type of
>>> the error if we want it.
>>>
>>>
>>> On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 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

 func foo() -> Int‽ { ... }

 if let x = foo() {
 // x is Int
 } else {
 // somehow access the error
 }

 guard let x = foo() else {
 // Again somehow access the error
 }

 func bar() throws -> String { ... }
 let x = try‽ bar()   // x is String‽
 let y = x!  // y is String

 // Possibly even make it throw? (just using a random symbol again)
 let z = try x¡


 On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:

> This is clearly a fine addition to the standard library; even Swift's
> Error Handling Rationale (https://github.com/apple/swif
> t/blob

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

[Stephen Canon via swift-evolution]

> 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 
> mailto: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 better 
> modeled with a more specific type than [Float], like SCNVector4 or 
> simd.float4 or your own type, which also solves this problem:
> 
> import SceneKit
> let vertexData = SCNVector4(1, 0, 0.5, 1)
> 
> import simd
> let vertexData = float4(1, 0, 0.5, 1)
> 
> (NB both of these frameworks are Apple-specific).
> 
> - Steve
> 
> Sent from my iPhone 
> 
> If @_fixed_layout was supported this would be sensible, but most graphics 
> frameworks expect a plain buffer of floats and the packing order is implicit. 
> We can’t model vertex vectors with Swift structs because we can’t safely 
> pointer-cast them to an array of floats.

SCNVector4 is a C struct and hence has fixed layout. simd.float4 fixes its 
ordering by having a single field that is an LLVM ext-vector type. Both can be 
safely converted to a buffer of floats.

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

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

[Kelvin Ma via swift-evolution]

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 better
> modeled with a more specific type than [Float], like SCNVector4 or
> simd.float4 or your own type, which also solves this problem:
>
> import SceneKit
> let vertexData = SCNVector4(1, 0, 0.5, 1)
>
> import simd
> let vertexData = float4(1, 0, 0.5, 1)
>
> (NB both of these frameworks are Apple-specific).
>
> - Steve
>
> Sent from my iPhone
>

If @_fixed_layout was supported this would be sensible, but most graphics
frameworks expect a plain buffer of floats and the packing order is
implicit. We can’t model vertex vectors with Swift structs because we can’t
safely pointer-cast them to an array of floats.


>
> On Nov 3, 2017, at 14:58, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 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 vertexData = [ 1.0h, 0.0h, 0.5h, 1.0h]
>>
>>
>> Thanks!
>> ___
>> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Steve Canon via swift-evolution]

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, which also solves this problem:

import SceneKit
let vertexData = SCNVector4(1, 0, 0.5, 1)

import simd
let vertexData = float4(1, 0, 0.5, 1)

(NB both of these frameworks are Apple-specific).

- Steve

Sent from my iPhone

> On Nov 3, 2017, at 14:58, Tony Allevato via swift-evolution 
>  wrote:
> 
> 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 
>>  wrote:
>> 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 vertexData = [ 1.0h, 0.0h, 0.5h, 1.0h]
>> 
>> 
>> Thanks!
>> ___
>> 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] f suffix for float32 literals, h suffix for float16 literals

[Tony Allevato via swift-evolution]

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 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 vertexData = [ 1.0h, 0.0h, 0.5h, 1.0h]
>
>
> Thanks!
> ___
> 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] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

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

in the example above "View" - a very similar concept between macOS and
iOS/tvOS/watchOS.
in case of doubts - command click is always at the finger tips.


> Which methods are you actually allowed to use? What should code completion
> show you?
>

autocomplete shows the relevant methods on each platform correctly.

2. The type alias is only useful when the naming of the methods/properties
> is identical and the sequence of calls you have to make is identical, which
> very often isn’t the case. You end up needing conditional compilation
> anyway for cases where you only need to make a call on one platform, or
> where the method you have to call is named slightly different or takes
> different arguments.
>

if the differences are minute i'm creating my own extension methods to make
the difference non existent.

example: layer is optional on OSX and non optional on iOS. the difference
is minute and i can make this difference non existent, e.g. by:

extension UIView {

var viewLayer: CALayer? {

return layer

}

}

and a similar thing on OSX, and afterwards i have single API on both
platforms with no differences.

You end up needing conditional compilation anyway for cases where you only
> need to make a call on one platform, or where the method you have to call
> is named slightly different or takes different arguments.
>

>

i rarely have to use conditional compilation and even when have to do so i
normally hide it inside the relevant "utility" extensions, from then on i
don't see anything "conditional" within the normal app sources.


> Out of the strategies I’ve seen used for cross-platform code this one was
> the most frustrating to work with in my experience.
>

quite the contrary to me - the best possible experience with such an
approach (during many years of experience ftm)


> My argument is that there should be no ledger in the first place. IMO you
>> haven’t made the case for that requirement.
>>
> the real-world example would be:

case 1. you have a single page of paper on hands saying: "partial contract
A. continued elsewhere. Blah, blah". you look around and within a multitude
of papers on the table you managed to find another sheet of paper with
"partial contract A. continued elsewhere. Blah, blah". in order to find the
whole thing you will have to look in all papers on your table, then in the
shelve and then in the whole building (module boundaries)

case 2. you have a single page of paper on hands saying: "contract A.
continued with part B elsewhere. blah, blah". you look around and within a
multitude of papers on the table you managed to find another sheet of paper
with: "part B of contract A, blah, blah". at that point you know that you
found everything, don't need to look on the shelve or in the whole building.

case 3. you have a single page of paper on hands saying: "contract A.
continued with part B elsewhere. blah, blah". you look around the whole
building and found no "part B". at this point you know - something is lost,
and act accordingly.

i mean this:
>
> class MyView: UIView {
> optional part Drawing
> }
>
> part Drawing of MyView { //  forgot to include this into target
> override func drawRect(...) {
> .
> }
> }
>
> the app compiles but doesn't work correctly.
>
>
> That example doesn’t make any sense.
>

i don't see why (and I am not talking about cross platform code at this
point). i have instances like these implemented via extensions in a day to
day code. the split of the class into files was done merely for organising
purposes, to keep file size manageable.

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

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

[Nate Cook via swift-evolution]

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 types in the stdlib.

Proposal draft is here: 
https://github.com/natecook1000/swift-evolution/blob/756370431682f41cfd9a63e39b81a96ccae467d9/proposals/-stdlib-index-types-hashable.md
Implementation here: 
https://github.com/apple/swift/compare/master...natecook1000:nc-index-hashable

Thanks!
Nate


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

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

[nick ralabate via swift-evolution]

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 vertexData = [ 1.0h, 0.0h, 0.5h, 1.0h]


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

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

[Adam Kemp via swift-evolution]

> 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 people working on the same code base tried 
> that, and it was much worse.
> 
> please provide more details on this. i was and still using such a technique, 
> so want to be prepared for those pitfalls before i actually encounter them.

1. You end up with a whole section of type aliases at the top of the file, and 
as you read the file it’s hard to understand what those types actually 
represent. Which methods are you actually allowed to use? What should code 
completion show you? Nothing is as it seems.

2. The type alias is only useful when the naming of the methods/properties is 
identical and the sequence of calls you have to make is identical, which very 
often isn’t the case. You end up needing conditional compilation anyway for 
cases where you only need to make a call on one platform, or where the method 
you have to call is named slightly different or takes different arguments.

Out of the strategies I’ve seen used for cross-platform code this one was the 
most frustrating to work with in my experience.

> My argument is that there should be no ledger in the first place. IMO you 
> haven’t made the case for that requirement.
> 
> If you forget to implement a protocol then ...
> 
> i mean this:
> 
> class MyView: UIView {
> optional part Drawing
> }
> 
> part Drawing of MyView { //  forgot to include this into target
> override func drawRect(...) {
> .
> }
> }
> 
> the app compiles but doesn't work correctly.

That example doesn’t make any sense. You wouldn’t override a drawRect function 
in the shared file because that function is overriding a platform-specific 
function. This is exactly the use case I gave an example for. What you would do 
instead is override the platform-specific draw function in a platform-specific 
file and then redirect to a shared implementation that has a cross-platform 
interface.

In general I would say you shouldn’t implement a protocol method for a protocol 
not declared in the same file or override a method of a superclass not 
explicitly mentioned in that file. That’s just a bad practice. Instead you 
would put that function in the same file as the protocol or superclass is 
mentioned and then, if needed, redirect to another function in another file. 
Then if you leave out that file it won’t compile because you’ll be missing a 
function.

Trust me, this works very well in practice. I never once ran into a bug like 
that over several years of doing things this way.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mike Kluev via swift-evolution]

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. i was and still using such a
technique, so want to be prepared for those pitfalls before i actually
encounter them.


> I will concede that there are other techniques for cross-platform code
> that might be considered even cleaner. This isn’t the only technique, and I
> won’t claim that it’s the best technique, but it is a very useful technique
> that I have seen used very effectively. It would be nice to be able to have
> it as an option.
>
> having said that, yes, i can see your point. my fear is that it will be
> (1) too fragile (e.g. you have "TableViewDelegate" in the ledger and just
> forgot to include the relevant file in the target - the app compiles but
> then misbehaves,
>
>
> My argument is that there should be no ledger in the first place. IMO you
> haven’t made the case for that requirement.
>

> If you forget to implement a protocol then ...
>

i mean this:

class MyView: UIView {
optional part Drawing
}

part Drawing of MyView { //  forgot to include this into target
override func drawRect(...) {
.
}
}

the app compiles but doesn't work correctly.

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

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

[Dave DeLong via swift-evolution]

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 operator multiple times in 
the calling function: the callStackSymbols alone wouldn’t necessarily be enough 
to disambiguate which usage of the operator you should be looking at.

Dave

> On Nov 3, 2017, at 11:40 AM, Mike Kluev  wrote:
> 
> 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 
> > off-the-table for Swift 5, and (I’m guessing) unlikely for Swift 6 too.
> 
> > Personally I’d like to be able to better debug my apps in Swift 4.1 rather 
> > than waiting another 2 or 3 years for a magical macro system to somehow 
> > solve this.
> 
> if that's just for debugging -- consider using Thread.callStackSymbols
> 
> last i checked it has the entries in the mangled form, but probably it's (1) 
> good enough for debugging purposes and (2) possible to de-mangle them somehow.
> 
> Mike
> 

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

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

[Mike Kluev via swift-evolution]

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
off-the-table for Swift 5, and (I’m guessing) unlikely for Swift 6 too.

> Personally I’d like to be able to better debug my apps in Swift 4.1
rather than waiting another 2 or 3 years for a magical macro system to
somehow solve this.

if that's just for debugging -- consider using Thread.callStackSymbols

last i checked it has the entries in the mangled form, but probably it's
(1) good enough for debugging purposes and (2) possible to de-mangle them
somehow.

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

[swift-evolution] Zero-copy String buffer access

[Cory Benfield via swift-evolution]

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 affordances for this use-case. The 
withCString method, the utf8CString property, and the cString(using:) functions 
are all very effective at providing the most-common case: a NULL-terminated 
string suitable for passing into most libc functions. However, using any of 
these affordances will always incur a memory copy, as Swift needs to not just 
ensure that the bytes making up the String are in contiguous memory, but also 
need to append a NULL byte to those strings for C safety.

This is a bit frustrating when working with C libraries that accept strings in 
the form of pointer + length, and so do not require NULL-termination, such as 
libicu. In these cases we are always required to incur the overhead of a memory 
copy, even in situations when the underlying String representation is 
contiguous, all in the name of appending a NULL byte we don’t actually need. 
Worse, the pointers provided by those methods are not BufferPointers, so they 
don’t carry their length around with them, requiring that another function call 
be used to determine the length of the pointer.

It would be convenient to have one or more additional functions that allow us 
to get access to a contiguous representation of bytes making up the string 
without appending a NULL byte, as a BufferPointer. The guarantees of these 
functions would be:

1. If the underlying string is stored in contiguous memory; AND
2. It is stored in the encoding the user has requested; THEN
3. An UnsafeBufferPointer will be returned that points to the underlying 
storage, without NULL-termination; OTHERWISE
4. A new contiguous buffer will be allocated and the string will be copied into 
it, with no NULL-termination.

Of course, I’ve used the word “return” here, but in practice all of these 
functions would be best used as with* style functions that accept trailing 
non-escaping closures.

The advantage of these functions is that they avoid unnecessary copying of 
memory in circumstances when the internal String representation was already 
suitable for passing to the C library. In the case of libraries like libicu, 
this halves the number of memory accesses in common-cases (e.g. passing a UTF-8 
string), which can provide substantial improvements to both performance and 
memory usage on hot code paths.

Does this seem like it’s of interest to anyone else?

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

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

[Adam Kemp via swift-evolution]

> 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 cross-platform classes into platform-specific 
> files. The idea is that each target contains a different subset of the files. 
> Consider a case where two platforms are similar enough to share some code but 
> not all code. For instance:
> 
>  
> i think we need a better real-world example, as in this one it's probably 
> easier to have "View" defined as a type alias to either UIView or NSView 
> depending upon a platform and similarly define currentGraphicsContext() to be 
> either UIGraphicsGetCurrentContext() or 
> NSGraphicsContext.currentContext()?.CGContext depending upon a platform and 
> have a single code base afterwords:

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. Partial classes make for a much cleaner 
implementation, and they avoid conditional compilation.

I will concede that there are other techniques for cross-platform code that 
might be considered even cleaner. This isn’t the only technique, and I won’t 
claim that it’s the best technique, but it is a very useful technique that I 
have seen used very effectively. It would be nice to be able to have it as an 
option.

> having said that, yes, i can see your point. my fear is that it will be (1) 
> too fragile (e.g. you have "TableViewDelegate" in the ledger and just forgot 
> to include the relevant file in the target - the app compiles but then 
> misbehaves,

My argument is that there should be no ledger in the first place. IMO you 
haven’t made the case for that requirement.

If you forget to implement a protocol then your build will fail because either 
1) you claimed to implement it and didn’t or 2) you didn’t claim to implement 
it and then tried to use that class somewhere that expects an object conforming 
to the protocol. This was never a problem. We have a type safe language. Even 
if you come up with some corner case where this could actually happen it falls 
squarely into the realm of bugs that would never ship (i.e., it will be obvious 
very quickly that something is wrong).

> and (2) open for abuse.

Again, we have to trust our developers to some extent. I worked in a large 
codebase with a large team of developers and not once did anyone abuse this.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Mike Kluev via swift-evolution]

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
> files. Consider a case where two platforms are similar enough to share some
> code but not all code. For instance:
>
>
i think we need a better real-world example, as in this one it's probably
easier to have "View" defined as a type alias to either UIView or NSView
depending upon a platform and similarly define currentGraphicsContext() to
be either UIGraphicsGetCurrentContext() or
NSGraphicsContext.currentContext()?.CGContext depending upon a platform and
have a single code base afterwords:

class PresentationView: View {

private func draw(inContext context: CGContext) {

// Shared CoreGraphics drawing

}



func draw(_ rect: CGRect) {

self.draw(inContext: currentGraphicsContext())

}

}


having said that, yes, i can see your point. my fear is that it will be (1)
too fragile (e.g. you have "TableViewDelegate" in the ledger and just
forgot to include the relevant file in the target - the app compiles but
then misbehaves, and (2) open for abuse.


alternative 1 - it's not too hard to put an empty:


part Feature of SomeClass {}


for the relevant platform


alternative 2 - have this in the ledger:


class Some {

part Feature1

optional part Feature2

}


as an "opt-in" to the behaviour you want.


i think this type of refinement can be done at some later stage. after all,
we do not have even (much needed IMHO) optional protocol methods without
resorting to @objc as of now...


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

[swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

[Florent Vilmart via swift-evolution]

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 full 
copy/paste of the JSONEncoder.swift file and playing with the internals. I also 
wanted to implement a simple QueryStringEncoder/Decoder that would properly 
encode / decode a query string.

The internally defined classes are proven a very powerful tool of reflection as 
well, being able to collect / untransform a series of containers safely into a 
strongly typed swift object.

The pitch:

- Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data
- Make _JSONEncoder / _JSONDecoder open classes
- Mark public all container implementations of UnkeyedEncodingContainers etc...
- Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't 
conflict with JSONEncoder / JSONDecoder but also denotes they conform to 
Encoder.

Opening those API's isn't for the general Codable implementation, the 
JSONEncoder/JSONDecoder should stay as-is but it's intended to reduce the 
amount of boiler plate one would need to implement in order to provide 
different serialization mechanism / strategy.


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

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

[Adam Kemp via swift-evolution]

> 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 so. and vice versa.
> 
> Mike
> 

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 files. Consider a 
case where two platforms are similar enough to share some code but not all 
code. For instance:

Class.swift
Class.UIKit.swift // Used by iOS + watchOS
Class.iOS.swift
Class.watchOS.swift
Class.macOS.swift

There are three targets, and two of the targets include Class.UIKit.swift but 
not the third. So what do you put in the ledger?

For a real-world example, consider a custom view that is used for presenting 
content in an app that shares code on iOS, tvOS, and macOS. Much of the logic 
for this is shared, including rendering which is done using CoreGraphics. You 
could write that class something like this:

PresentationView.swift:
import CoreGraphics

partial class PresentationView {

private func draw(inContext context: CGContext) {
// Shared CoreGraphics drawing
}

}

PresentationView.UIKit.swift: // Used by iOS + tvOS
import UIKit

partial class PresentationView : UIView {
func draw(_ rect: CGRect) {
self.draw(inContext: UIGraphicsGetCurrentContext())
}
}

PresentationView.AppKit.swift:
import AppKit

partial class PresentationView : NSView {
func draw(_ dirtyRect: NSRect) {
self.draw(inContext: NSGraphicsContext.currentContext()?.CGContext)
}
}

This is exactly the technique that I’ve used in the past (in C#) to share code 
across iOS, Android, macOS, and WPF. It’s really powerful, but the ledger would 
make it much harder.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Benjamin G via swift-evolution]

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, 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.
>
> Elia Cereda
>
> Il giorno 03 nov 2017, alle ore 13:10, Benjamin G via swift-evolution <
> swift-evolution@swift.org> ha scritto:
>
> 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 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 type of
>> the error if we want it.
>>
>>
>> On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> 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
>>>
>>> func foo() -> Int‽ { ... }
>>>
>>> if let x = foo() {
>>> // x is Int
>>> } else {
>>> // somehow access the error
>>> }
>>>
>>> guard let x = foo() else {
>>> // Again somehow access the error
>>> }
>>>
>>> func bar() throws -> String { ... }
>>> let x = try‽ bar()   // x is String‽
>>> let y = x!  // y is String
>>>
>>> // Possibly even make it throw? (just using a random symbol again)
>>> let z = try x¡
>>>
>>>
>>> On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 This is clearly a fine addition to the standard library; even Swift's
 Error Handling Rationale (https://github.com/apple/swif
 t/blob/master/docs/ErrorHandlingRationale.rst) mentions such an
 addition

 What separates standard library types from other types is that they
 have language level support, and the wrapping and unwrapping syntax here
 could definitely benefit from it (`.unwrap()`--which should be
 `.unwrapped()` incidentally--is so much less elegant in comparison to `?`
 and `!` for optionals (not that `Result` should use the exact such syntax
 for a distinct operation)). It would be a shame to transpose a third-party
 `Result` to the standard library without considering if any such tweaks
 would substantially improve ergonomics, interconversion with Optional and
 throws, etc.


 On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
 swift-evolution@swift.org> wrote:

> Swift-Evolution:
> I’ve written a first draft of a proposal to add Result to the
> standard library by directly porting the Result type used in Alamofire
> to the standard library. I’d be happy to implement it (type and tests for
> free!) if someone could point me to the right place to do so. I’m not
> including it directly in this email, since it includes the full
> implementation and is therefore quite long. (Discourse, please!)
>
> https://github.com/jshier/swift-evolution/blob/master/propos
> als/0187-add-result-to-the-standard-library.md
>
>
> Thanks,
>
> Jon Shier
>
>
>
> ___
> 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
>>>
>>>
>>
> ___
> 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] Proposal: Allow operators to have parameters with default values

[Dave DeLong via swift-evolution]

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.

Personally I’d like to be able to better debug my apps in Swift 4.1 rather than 
waiting another 2 or 3 years for a magical macro system to somehow solve this.

Dave

> On Nov 2, 2017, at 6:50 PM, Eric Summers  wrote:
> 
> I think this makes more sense as part of a hygienic macro system.  These 
> “hidden” parameters could be made available to standard functions using some 
> sort of convention to exclude them from autocompletion.
> 
> Eric
> 
>> On Nov 2, 2017, at 8:35 PM, Tony Allevato via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I like this idea as it's presented here, for the debugging/logging reasons 
>> that you stated.
>> 
>> Should we tighten the shackles a little be to validate that *only* the 
>> special #file/#line/#function directives can be permitted for these extra 
>> parameters? I'm struggling to think of a case where we would want to allow 
>> something else, since there's no way to provide the values for them in a 
>> standard call.
>> 
>> 
>> On Thu, Nov 2, 2017 at 5:26 PM Dave DeLong via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Hi SE,
>> 
>> As I’ve been using my own custom operators like “?!”, “!!”, or operators 
>> provided by libraries (<|, ~>, etc), I’ve often wanted to capture the #file 
>> and #line where the operators are used to make debugging their use a lot 
>> easier.
>> 
>> For example, given something the unwrap-or-die operator 
>> (https://github.com/erica/swift-evolution/blob/2c1be72e34c970894e4ba7ed9df5cee3298d4282/proposals/-unwrap-or-die.md
>>  
>> ),
>>  you’d want to capture the #file and #line so you could pass it on to the 
>> underlying call to fatalError().
>> 
>> Or, if you’re using a custom bind operator and something goes wrong, it’d be 
>> great to be able to capture the file and line where the operator is used so 
>> you can quickly triage the bug in your code.
>> 
>> Unfortunately, Swift has the hard limit the the implementations of unary 
>> operators may have one-and-only-one parameter, and that binary operators may 
>> only have two parameters.
>> 
>> I’d like to propose a very minor change to Swift, whereby operator 
>> implementations may have more than their one or two parameters, provided 
>> that all subsequent parameters come with a default value. This would make it 
>> trivial to add in #file, #line, #function, etc to your operator 
>> implementations, which you can then capture for your own purposes.
>> 
>> An implementation of this change, with passing tests, can be found here: 
>> https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697
>>  
>> 
>> 
>> 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
> 

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

Re: [swift-evolution] Abstract methods

[C. Keith Ray via swift-evolution]

(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 Nov 3, 2017, at 8:33 AM, C. Keith Ray via swift-evolution 
>  wrote:
> 
> 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?
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
> * http://agilesolutionspace.blogspot.com/
> 
>> On Nov 2, 2017, at 10:07 PM, Gwendal Roué via swift-evolution 
>>  wrote:
>> 
>> 
>>> Le 3 nov. 2017 à 04:29, Brent Royal-Gordon via swift-evolution 
>>>  a écrit :
>>> 
>>> I think we should beef up protocols a little bit so that they can serve the 
>>> role of abstract classes. 
>> 
>> That would be great.
>> 
>> Back in the day, the proposal SE-0026 "Abstract classes and methods" was 
>> deferred, with the following rationale: 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/56.html
>> 
>> This rationale is great because it lists a few use cases for abstract class 
>> that protocols can't mimic today.
>> 
>> Gwendal
>> 
>> ___
>> 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] Abstract methods

[C. Keith Ray via swift-evolution]

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?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Nov 2, 2017, at 10:07 PM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> 
>> Le 3 nov. 2017 à 04:29, Brent Royal-Gordon via swift-evolution 
>>  a écrit :
>> 
>> I think we should beef up protocols a little bit so that they can serve the 
>> role of abstract classes. 
> 
> That would be great.
> 
> Back in the day, the proposal SE-0026 "Abstract classes and methods" was 
> deferred, with the following rationale: 
> https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/56.html
> 
> This rationale is great because it lists a few use cases for abstract class 
> that protocols can't mimic today.
> 
> Gwendal
> 
> ___
> 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] Adding Result to the Standard Library

[Elia Cereda via swift-evolution]

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. 

Elia Cereda

> Il giorno 03 nov 2017, alle ore 13:10, Benjamin G via swift-evolution 
>  ha scritto:
> 
> 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 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 type of the 
> error if we want it. 
> 
> 
> On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 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
> 
> func foo() -> Int‽ { ... }
> 
> if let x = foo() {
> // x is Int
> } else {
> // somehow access the error
> }
> 
> guard let x = foo() else {
> // Again somehow access the error
> }
> 
> func bar() throws -> String { ... }
> let x = try‽ bar()   // x is String‽
> let y = x!  // y is String
> 
> // Possibly even make it throw? (just using a random symbol again)
> let z = try x¡
> 
> 
> On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> This is clearly a fine addition to the standard library; even Swift's Error 
> Handling Rationale 
> (https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst 
> ) 
> mentions such an addition
> 
> What separates standard library types from other types is that they have 
> language level support, and the wrapping and unwrapping syntax here could 
> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()` 
> incidentally--is so much less elegant in comparison to `?` and `!` for 
> optionals (not that `Result` should use the exact such syntax for a distinct 
> operation)). It would be a shame to transpose a third-party `Result` to the 
> standard library without considering if any such tweaks would substantially 
> improve ergonomics, interconversion with Optional and throws, etc.
> 
> 
> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Swift-Evolution:
>   I’ve written a first draft of a proposal to add Result to the 
> standard library by directly porting the Result type used in Alamofire to 
> the standard library. I’d be happy to implement it (type and tests for free!) 
> if someone could point me to the right place to do so. I’m not including it 
> directly in this email, since it includes the full implementation and is 
> therefore quite long. (Discourse, please!) 
> 
> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>  
> 
> 
> 
> Thanks, 
> 
> Jon Shier
> 
> 
> 
> ___
> 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 
> 
> 
> 
> 
> ___
> 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] Adding Result to the Standard Library

[Wallacy via swift-evolution]

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 functions too
}

And some compiler magics to make Optional always to be convertible
to Optional (losing Error info of course)... And support to optional
chaining and other current optional tricks.

In this case:

let some = try? foo() // some is Optional

some?.bar() // works

And we can do:

switch some{
   case .Some(let value):
   // ...
  case .None(let error):
  //
}

Other idea was presented in Swift 2/3 time frame was just:

enum Optional{
 case Some(T)
 case None
 var payload:Any!
}


I am not saying that this is the best way, but in fact it is better to
think about what we can do to improve the current scenario, than to
introduce another type that may or may not make everything more confusing.


Em sex, 3 de nov de 2017 às 09:13, Benjamin G via swift-evolution <
swift-evolution@swift.org> escreveu:

> 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 type of
> the error if we want it.
>
>
> On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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
>>
>> func foo() -> Int‽ { ... }
>>
>> if let x = foo() {
>> // x is Int
>> } else {
>> // somehow access the error
>> }
>>
>> guard let x = foo() else {
>> // Again somehow access the error
>> }
>>
>> func bar() throws -> String { ... }
>> let x = try‽ bar()   // x is String‽
>> let y = x!  // y is String
>>
>> // Possibly even make it throw? (just using a random symbol again)
>> let z = try x¡
>>
>>
>> On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> This is clearly a fine addition to the standard library; even Swift's
>>> Error Handling Rationale (
>>> https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst)
>>> mentions such an addition
>>>
>>> What separates standard library types from other types is that they have
>>> language level support, and the wrapping and unwrapping syntax here could
>>> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
>>> incidentally--is so much less elegant in comparison to `?` and `!` for
>>> optionals (not that `Result` should use the exact such syntax for a
>>> distinct operation)). It would be a shame to transpose a third-party
>>> `Result` to the standard library without considering if any such tweaks
>>> would substantially improve ergonomics, interconversion with Optional and
>>> throws, etc.
>>>
>>>
>>> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Swift-Evolution:
 I’ve written a first draft of a proposal to add Result to the
 standard library by directly porting the Result type used in Alamofire
 to the standard library. I’d be happy to implement it (type and tests for
 free!) if someone could point me to the right place to do so. I’m not
 including it directly in this email, since it includes the full
 implementation and is therefore quite long. (Discourse, please!)


 https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md


 Thanks,

 Jon Shier



 ___
 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
>>
>>
> ___
> 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] continuations - "extensions on steroids" idea

[Mike Kluev via swift-evolution]

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 choices
> and makes future development harder. Having a new construct for in-module
> class organization neatly solves the problem.
>

well said


> (I still want C++’s protected scope too though, in case there was any
> doubt).
>

+1

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

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

[Mike Kluev via swift-evolution]

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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Benjamin G via swift-evolution]

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 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 type of
> the error if we want it.
>
>
> On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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
>>
>> func foo() -> Int‽ { ... }
>>
>> if let x = foo() {
>> // x is Int
>> } else {
>> // somehow access the error
>> }
>>
>> guard let x = foo() else {
>> // Again somehow access the error
>> }
>>
>> func bar() throws -> String { ... }
>> let x = try‽ bar()   // x is String‽
>> let y = x!  // y is String
>>
>> // Possibly even make it throw? (just using a random symbol again)
>> let z = try x¡
>>
>>
>> On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> This is clearly a fine addition to the standard library; even Swift's
>>> Error Handling Rationale (https://github.com/apple/swif
>>> t/blob/master/docs/ErrorHandlingRationale.rst) mentions such an addition
>>>
>>> What separates standard library types from other types is that they have
>>> language level support, and the wrapping and unwrapping syntax here could
>>> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
>>> incidentally--is so much less elegant in comparison to `?` and `!` for
>>> optionals (not that `Result` should use the exact such syntax for a
>>> distinct operation)). It would be a shame to transpose a third-party
>>> `Result` to the standard library without considering if any such tweaks
>>> would substantially improve ergonomics, interconversion with Optional and
>>> throws, etc.
>>>
>>>
>>> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Swift-Evolution:
 I’ve written a first draft of a proposal to add Result to the
 standard library by directly porting the Result type used in Alamofire
 to the standard library. I’d be happy to implement it (type and tests for
 free!) if someone could point me to the right place to do so. I’m not
 including it directly in this email, since it includes the full
 implementation and is therefore quite long. (Discourse, please!)

 https://github.com/jshier/swift-evolution/blob/master/propos
 als/0187-add-result-to-the-standard-library.md


 Thanks,

 Jon Shier



 ___
 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
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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 swift-evolution 
 wrote:

Swift-Evolution:
I’ve written a first draft of a proposal to add Result to the standard 
library by directly porting the Result type used in Alamofire to the 
standard library. I’d be happy to implement it (type and tests for free!) if 
someone could point me to the right place to do so. I’m not including it 
directly in this email, since it includes the full implementation and is 
therefore quite long. (Discourse, please!) 

https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md

I’m generally supportive of this, but the design of such a thing forces another 
contentious issue: whether the error handling model should be extended to 
support "typed throws”.  Without result, we can carry on pushing the "typed 
throws” debate down the road.  Adding it would force that issue to be decided, 
which is complicated.

-Chris


___
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] Adding Result to the Standard Library

[Benjamin G via swift-evolution]

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 type of
the error if we want it.


On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution <
swift-evolution@swift.org> wrote:

> 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
>
> func foo() -> Int‽ { ... }
>
> if let x = foo() {
> // x is Int
> } else {
> // somehow access the error
> }
>
> guard let x = foo() else {
> // Again somehow access the error
> }
>
> func bar() throws -> String { ... }
> let x = try‽ bar()   // x is String‽
> let y = x!  // y is String
>
> // Possibly even make it throw? (just using a random symbol again)
> let z = try x¡
>
>
> On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> This is clearly a fine addition to the standard library; even Swift's
>> Error Handling Rationale (https://github.com/apple/swif
>> t/blob/master/docs/ErrorHandlingRationale.rst) mentions such an addition
>>
>> What separates standard library types from other types is that they have
>> language level support, and the wrapping and unwrapping syntax here could
>> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
>> incidentally--is so much less elegant in comparison to `?` and `!` for
>> optionals (not that `Result` should use the exact such syntax for a
>> distinct operation)). It would be a shame to transpose a third-party
>> `Result` to the standard library without considering if any such tweaks
>> would substantially improve ergonomics, interconversion with Optional and
>> throws, etc.
>>
>>
>> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Swift-Evolution:
>>> I’ve written a first draft of a proposal to add Result to the
>>> standard library by directly porting the Result type used in Alamofire
>>> to the standard library. I’d be happy to implement it (type and tests for
>>> free!) if someone could point me to the right place to do so. I’m not
>>> including it directly in this email, since it includes the full
>>> implementation and is therefore quite long. (Discourse, please!)
>>>
>>> https://github.com/jshier/swift-evolution/blob/master/propos
>>> als/0187-add-result-to-the-standard-library.md
>>>
>>>
>>> Thanks,
>>>
>>> Jon Shier
>>>
>>>
>>>
>>> ___
>>> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Benjamin G via swift-evolution]

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 i'm not sure how feasible that is.

On Thu, Nov 2, 2017 at 7:15 PM, Jon Shier via swift-evolution <
swift-evolution@swift.org> wrote:

> You don’t lose it, it’s just behind `Error`. You can cast out whatever
> strong error type you need without having to bind an entire type to it
> generically. If getting a common error type out happens a lot, I usually
> add a convenience property to `Error` to do the cast for me. Plus, having
> to expose an entire new error wrapper is just a non starter for me and
> doesn’t seem necessary, given how Result is currently used in the community.
>
>
> Jon
>
>
> On Nov 2, 2017, at 2:12 PM, Dave DeLong  wrote:
>
> I think I’d personally rather see this done with a generic error as well,
> like:
>
> enum GenericResult {
> case success(T)
> case failure(E)
> }
>
> And a typealias:
>
> typealias Result = GenericResult
>
> This would require an “AnyError” type to type-erase a specific Error, but
> I’ve come across many situations where a strongly-typed error is *incredibly
> *useful, and I’d be reluctant to see that thrown away.
>
> Dave
>
> On Nov 2, 2017, at 12:08 PM, Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Swift-Evolution:
> I’ve written a first draft of a proposal to add Result to the standard
> library by directly porting the Result type used in Alamofire to the
> standard library. I’d be happy to implement it (type and tests for free!)
> if someone could point me to the right place to do so. I’m not including it
> directly in this email, since it includes the full implementation and is
> therefore quite long. (Discourse, please!)
>
> https://github.com/jshier/swift-evolution/blob/master/
> proposals/0187-add-result-to-the-standard-library.md
>
>
> Thanks,
>
> Jon Shier
>
>
> ___
> 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] Adding Result to the Standard Library

[Nick Keets via swift-evolution]

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

func foo() -> Int‽ { ... }

if let x = foo() {
// x is Int
} else {
// somehow access the error
}

guard let x = foo() else {
// Again somehow access the error
}

func bar() throws -> String { ... }
let x = try‽ bar()   // x is String‽
let y = x!  // y is String

// Possibly even make it throw? (just using a random symbol again)
let z = try x¡


On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> This is clearly a fine addition to the standard library; even Swift's
> Error Handling Rationale (https://github.com/apple/swift/blob/master/docs/
> ErrorHandlingRationale.rst) mentions such an addition
>
> What separates standard library types from other types is that they have
> language level support, and the wrapping and unwrapping syntax here could
> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
> incidentally--is so much less elegant in comparison to `?` and `!` for
> optionals (not that `Result` should use the exact such syntax for a
> distinct operation)). It would be a shame to transpose a third-party
> `Result` to the standard library without considering if any such tweaks
> would substantially improve ergonomics, interconversion with Optional and
> throws, etc.
>
>
> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Swift-Evolution:
>> I’ve written a first draft of a proposal to add Result to the standard
>> library by directly porting the Result type used in Alamofire to the
>> standard library. I’d be happy to implement it (type and tests for free!)
>> if someone could point me to the right place to do so. I’m not including it
>> directly in this email, since it includes the full implementation and is
>> therefore quite long. (Discourse, please!)
>>
>> https://github.com/jshier/swift-evolution/blob/master/propos
>> als/0187-add-result-to-the-standard-library.md
>>
>>
>> Thanks,
>>
>> Jon Shier
>>
>>
>>
>> ___
>> 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