Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Gor Gyolchanyan via swift-evolution]

One major thing to keep in mind is how exactly will it behave in generic 
contexts.
As a similar example, if you can do this:

func foo(pass parameter: A, to closure: (A) -> B) -> B {
closure(parameter)
}

func bar(one: Int, two: Double, three: String) {
print(“\(one) \(two) \(three)")
}

foo(pass: (1, 2.0, “3”), to: bar)

This used to work without generics, but If I’m not mistaken, a proposal was 
accepted to disallow passing tuples and the only argument of a multi-argument 
function, leaving this use case kinda magical.
This is an enormously useful feature for generic programming (especially with 
the lack of variadic generic types), because this allows us to define 
higher-order functions that operate on any type of function, regardless of 
their arity.

However we resolve the error issue, it has to behave in a similar way, so that 
throwing and non-throwing functions can be dealt with in a uniform way in a 
generic context without loss of information or security guarantees.

> On May 2, 2017, at 12:48 AM, Rod Brown  wrote:
> 
> 
>> On 2 May 2017, at 2:34 am, John McCall > > wrote:
>> 
>>> 
>>> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution 
>>> > wrote:
>>> I agree that the key problem with the current architecture that you're 
>>> alluding to is it can't be easily stored and transferred. Swift errors are 
>>> great for live action but holding and passing after the throwing event is 
>>> problematic, and this is an elegant solution. The storage issue is when 
>>> holding it as a property, and the transferring issue is when passing it to 
>>> a closure as a results of an asynchronous operation etc. These are both 
>>> definitely cases where storage of the type-or-error makes perfect sense.
>>> 
>>> I think the key problem getting this accepted by the Swift Team will be 
>>> that it doesn't currently have any specific use in the standard library. As 
>>> a low level set of types, errors are generated by the lower levels but 
>>> rarely stored, so the Standard library doesn't need the storage. Generally 
>>> the only place we have to do that is in end user code. And currently the 
>>> standard library doesn't have to support asynchronous operations natively, 
>>> so there's nothing inside the kit that would require it to do completion 
>>> handlers with errors.
>> 
>> We've definitely considered including a Result type, but our sense was that 
>> in an ideal world almost no code would be using it.  It's hard to imagine an 
>> ordinary API that ought to be returning a Result rather than throwing, and 
>> once you've defined that away, the major remaining use case is just to shift 
>> computation around, like with a completion handler.  That explicit 
>> computation-shifting pattern is something we're hoping to largely define 
>> away with something like C#'s async/await, which would leave Result as 
>> mostly just an implementation detail of such APIs.  We didn't want to spend 
>> a great deal of time designing a type that would end up being so marginal, 
>> especially if the changing role would lead us into different directions on 
>> the design itself.  We also didn't want to design a type that would become 
>> an obstacle to potential future language changes like, say, typed throws.
>> 
>> The downside, of course, is that as long as we lack that async/await design, 
>> computation-shifting isn't real great.
>> 
>> John.
> 
> This makes sense and is sensible. I’m curious how such an API would play with 
> the existing NSURLSession completion handlers and the like, but I’m sure the 
> community can design something appropriate.
> 
> I think the only remaining case is simply storing a result-or-error for later 
> handling, storage to disk, etc. I agree with your contention that the vast 
> majority of the use case for this type is for computation shifting. I think 
> it would and should be rare that we would want to “store” as a variable the 
> “result-or-error” type. Errors should be handled at runtime in the vast 
> majority of cases, presented to the user or otherwise handled, and then moved 
> on from, with the reason no longer being relevant.
> 
> As you say, in the meantime, it does leave computation-shifting a bit ad-hoc 
> and convoluted, but I think the community has standardized on the Result 
> temporary solution.
> 
>> 
>>> 
>>> This would therefore be an element in the standard library purely so we 
>>> don't have 50,000 different libraries with 50,000 different result types. 
>>> I'd love to see this standardised so frameworks were more compatible. I'm 
>>> just not sure whether the Core Team would see it as pressing to try and 
>>> officiate a certain type that they themselves don't use.
> 

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu via swift-evolution]

On Mon, May 1, 2017 at 9:34 PM, Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

> Currently, we have the Repeated type, which presents a single element
> as though it were a Collection.
>
> > for i in repeatElement(1, count: 3) { print(i) }
> 1
> 1
> 1
>
> > for i in repeatElement([1, 2, 3], count: 3) { print(i) }
> [1, 2, 3]
> [1, 2, 3]
> [1, 2, 3]
>
>
> However, we lack the ability for Collections to repeat their contents in a
> single list; basically, some kind of “flatMap” to repeatElement’s “map”. So
> I’d like to pitch a new API for repeated values.
>
> - We would add a RepeatCollection type, which loops over
> its base Collection a certain number of times (or until a maximum ‘count’).
>   Implementation might look something like this (https://gist.github.com/
> karwa/5228974a0b4dfd000a916f0aac2721c6), except that we’d add some
> optimised map(), filter() and contains() functions which apply the
> algorithm once to the base and multiply the result.
>
> - We would add 3 new functions to all Collections:
>
> /// Repeats the collection *itself* N times.
> ///
> func repeated(_ times: Int) -> RepeatCollection
>
> /// Repeats the collection’s *contents* N times.
> ///
> func repeatElements(_ times: Int) -> RepeatCollection
>
> /// Loops the collection’s contents to present a Collection of length N.
> ///
> func repeatElements(count: Int) -> RepeatCollection
>
>
> - We would replace the existing Repeated type with a typealias to
> RepeatCollection
> - The existing, top-level repeatElement(T, Int) function *could* stay,
> but could also be replaced with an incantation on CollectionOfOne. I’m
> fairly ambivalent about this point - it’d be nice to see the function go,
> but the replacement also isn’t obvious.
>
> Example usage of the new API:
>
> // Equivalent to repeatElement(1, count: 3)
>
> > for i in CollectionOfOne(1).repeatElements(3).forEach { print(i) }
> 1
> 1
> 1
>
> // Equivalent to repeatElement([1, 2, 3], count: 3)
>
> > for i in [1, 2, 3].repeated(3).forEach { print(i) }
> [1, 2, 3]
> [1, 2, 3]
> [1, 2, 3]
>
> // New, flat repetition
>
> > for i in [1, 2, 3].repeatElements(3) { print(i) }
> 1
> 2
> 3
> 1
> 2
> 3
> 1
> 2
> 3
>
> // New, flat repetition
>
> > for i in [1, 2, 3].repeatElements(count: 4) { print(i) }
> 1
> 2
> 3
> 1
>
> // Additional benefit: you can now repeat slices!
>
> > String(“yellow”.characters.dropFirst().dropLast().repeat(times: 3))
> “elloelloello"
>
>
> Thoughts?
>

OK, now as to your proposed APIs themselves, here are some critiques:

The issue you've identified with the cumbersome nature of CollectionOfOne
shows why repeatElement is currently a top-level function and intentionally
so. In brief, there's nothing special about Collection to make it the
obvious type on which to provide a `repeated` method. The _result_ of that
operation is a collection, but there's no reason the argument has to be.
The correct "type" on which to provide that method would be Any, IMO, but
of course we cannot provide extensions on Any. In general, in such
scenarios, the consistent design choice in the standard library is to
provide a free function.

Here, it is not inconsistent to _add_ something for repeating the elements
in a collection (to Collection itself) without also stuffing the existing
`repeatElement` functionality into Collection. TBH, the latter seems like
an orthogonal topic included for the express purpose of eliminating
top-level functions, without addressing the underlying reason for the
existence of these top-level functions in the first place (no extensions on
Any). So again, unrelated and worth setting aside, IMO.

Other minor points include that `repeatElements` doesn't meet standard API
naming guidelines. It should be `repeatingElements`. You also intuitively
tacked on a `times` argument label in the example usage even though your
proposed API doesn't have it. It suggests that `repeat[ing]Elements(3)` is
actually quite ambiguous: repeat the value 3, repeat the whole collection 3
times, or repeat so that the final count is 3? Better to have the label
always, I should think. Another point is that it'd take some justification
to include both flavors of `repeat[ing]Elements`, as repeating until a
final count is trivially composed with new one-sided ranges: `[1, 2,
3].repeatingElements(times: .max)[..<4]`.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu via swift-evolution]

On Mon, May 1, 2017 at 11:47 PM, Rod Brown  wrote:

>
> On 2 May 2017, at 2:33 pm, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Mon, May 1, 2017 at 11:22 PM, T.J. Usiyan  wrote:
>
>> Xi: "Does this gain something by being part of the standard library?"
>> Me: "This gains discoverability and standardization by being part of the
>> standard library."
>> Xi: "By definition, if it's in the standard library, it becomes
>> standardized and discoverable."
>>
>> We're in agreement, then?
>>
>
> No, you're missing the point entirely. Again, _anything_ gains
> "discoverability and standardization" by being included as part of the
> standard library. However, the standard library is deliberately small and
> is intended to stay that way. So, what should be in and what should be out?
> The question is: does this feature gain something by being part of the
> standard library which other features that are deliberately excluded (like
> left pad) do not?
>
>
> I’m going to back Xiaodi on this one. The standard library is the standard
> for the language, by definition. That comes with some great things, and
> some concerning things.
>
> If we decided anything that was generic and useful as a basis for
> programming got in, we wouldn’t call it the “Standard Library” - it would
> be the Kitchen Sink Library. It would be huge. The bar has to be set higher
> for the library.
>
> Why is the current repeat functionality in there? Because Strings use it.
> Why is it public? Because, like you, people noticed it and said “That’s
> great generic functionality, why not expose it, and let everyone use it?”
> But that isn’t the bar for adding things: the bar is far higher for them to
> be added. Especially now as we’re trying to mature Swift from it’s immature
> fast-moving state. This may be the bar for *exposing* generic things, but
> the higher bar of “is this core?” may not be met with this proposal.
>
> Don’t get me wrong, I think it’s a great idea. I just am not sure it meets
> the bar of “core”.
>

Heck, it may even meet the bar for "core"! But not even core things all go
into the standard library (for example, all of Foundation and Dispatch).

For instance, many people ask for additional math functionality here, and
the repeated statement from the core team is that they'd like to see it as
a third-party library, gain traction, then get nominated for inclusion as a
core library. But even then, notice: core, not standard.


> Repeating a collection endlessly is a useful ability.
>>
>
> I don't doubt it. Is your argument that any useful and commonly used
> feature should be part of the standard library? That's simply not the
> stated criteria for inclusion in the standard library. Hence, why
> Foundation exists outside of it. There's no point in debating these
> criteria, as (afaict) that's not up for debate. Again, I don't make the
> rules. I'm just saying they exist, and I'm arguing that we should abide by
> them.
>
>
>> Yes, it can be written on top of the standard library. It would be
>> generally nice not to require that *especially* when we can repeat single
>> elements without similar effort. The asymmetry is awkward to remember for
>> newbies and awkward to explain away  with "we want a focused library so…
>> the Thing A stays but this logically related Thing B can't be in even
>> though showing you the ability to do A does tend to lead you to ask after
>> Thing B."
>>
>>
>> On Mon, May 1, 2017 at 11:55 PM, Xiaodi Wu  wrote:
>>
>>> That's a tautological argument, though. By definition, if it's in the
>>> standard library, it becomes standardized and discoverable. This isn't at
>>> all a limiting principle for what goes into the library and what doesn't.
>>>
>>> And as I said, there are many commonly useful facilities that aren't
>>> part of the standard library, by design and not by oversight. Left pad is
>>> one of them.
>>>
>>> I'm trying to tease out whether this particular proposal meets the
>>> current bar for inclusion. If you believe left pad should be included, your
>>> beef is with the deliberate choice to have a small standard library, which
>>> as far as I know is not up for reconsideration.
>>>
>>> On Mon, May 1, 2017 at 22:41 T.J. Usiyan  wrote:
>>>
 This gains discoverability and standardization by being part of the
 standard library. New folks would not have to import some library or roll
 their own to get this reasonable to expect/hope or hope for functionality.
 Perhaps removing the old function isn't going to work but repeating
 collections is definitely something useful.

 Left padding for strings would be nice as well, but that is neither
 here nor there.

 On Mon, May 1, 2017 at 11:29 PM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:

> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner 
> 

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Rod Brown via swift-evolution]

> On 2 May 2017, at 2:33 pm, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Mon, May 1, 2017 at 11:22 PM, T.J. Usiyan  > wrote:
> Xi: "Does this gain something by being part of the standard library?"
> Me: "This gains discoverability and standardization by being part of the 
> standard library."
> Xi: "By definition, if it's in the standard library, it becomes standardized 
> and discoverable."
> 
> We're in agreement, then?
> 
> No, you're missing the point entirely. Again, _anything_ gains 
> "discoverability and standardization" by being included as part of the 
> standard library. However, the standard library is deliberately small and is 
> intended to stay that way. So, what should be in and what should be out? The 
> question is: does this feature gain something by being part of the standard 
> library which other features that are deliberately excluded (like left pad) 
> do not?

I’m going to back Xiaodi on this one. The standard library is the standard for 
the language, by definition. That comes with some great things, and some 
concerning things.

If we decided anything that was generic and useful as a basis for programming 
got in, we wouldn’t call it the “Standard Library” - it would be the Kitchen 
Sink Library. It would be huge. The bar has to be set higher for the library.

Why is the current repeat functionality in there? Because Strings use it. Why 
is it public? Because, like you, people noticed it and said “That’s great 
generic functionality, why not expose it, and let everyone use it?” But that 
isn’t the bar for adding things: the bar is far higher for them to be added. 
Especially now as we’re trying to mature Swift from it’s immature fast-moving 
state. This may be the bar for *exposing* generic things, but the higher bar of 
“is this core?” may not be met with this proposal.

Don’t get me wrong, I think it’s a great idea. I just am not sure it meets the 
bar of “core”.

> 
> Repeating a collection endlessly is a useful ability.
> 
> I don't doubt it. Is your argument that any useful and commonly used feature 
> should be part of the standard library? That's simply not the stated criteria 
> for inclusion in the standard library. Hence, why Foundation exists outside 
> of it. There's no point in debating these criteria, as (afaict) that's not up 
> for debate. Again, I don't make the rules. I'm just saying they exist, and 
> I'm arguing that we should abide by them.
>  
> Yes, it can be written on top of the standard library. It would be generally 
> nice not to require that *especially* when we can repeat single elements 
> without similar effort. The asymmetry is awkward to remember for newbies and 
> awkward to explain away  with "we want a focused library so… the Thing A 
> stays but this logically related Thing B can't be in even though showing you 
> the ability to do A does tend to lead you to ask after Thing B."
> 
> 
> On Mon, May 1, 2017 at 11:55 PM, Xiaodi Wu  > wrote:
> That's a tautological argument, though. By definition, if it's in the 
> standard library, it becomes standardized and discoverable. This isn't at all 
> a limiting principle for what goes into the library and what doesn't.
> 
> And as I said, there are many commonly useful facilities that aren't part of 
> the standard library, by design and not by oversight. Left pad is one of them.
> 
> I'm trying to tease out whether this particular proposal meets the current 
> bar for inclusion. If you believe left pad should be included, your beef is 
> with the deliberate choice to have a small standard library, which as far as 
> I know is not up for reconsideration.
> 
> On Mon, May 1, 2017 at 22:41 T.J. Usiyan  > wrote:
> This gains discoverability and standardization by being part of the standard 
> library. New folks would not have to import some library or roll their own to 
> get this reasonable to expect/hope or hope for functionality. Perhaps 
> removing the old function isn't going to work but repeating collections is 
> definitely something useful.
> 
> Left padding for strings would be nice as well, but that is neither here nor 
> there. 
> 
> On Mon, May 1, 2017 at 11:29 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  > wrote:
> 
> > On 2 May 2017, at 04:44, Xiaodi Wu  > > wrote:
> >
> > Does this gain something by being part of the standard library as opposed 
> > to being built on top of it?
> 
> Well, somebody thought repeatElement was general enough to make part of 
> the standard library. If we’re going to allow repeating a single item as a 
> Collection, we might as well allow generalise it to repeating any 

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu via swift-evolution]

On Mon, May 1, 2017 at 11:22 PM, T.J. Usiyan  wrote:

> Xi: "Does this gain something by being part of the standard library?"
> Me: "This gains discoverability and standardization by being part of the
> standard library."
> Xi: "By definition, if it's in the standard library, it becomes
> standardized and discoverable."
>
> We're in agreement, then?
>

No, you're missing the point entirely. Again, _anything_ gains
"discoverability and standardization" by being included as part of the
standard library. However, the standard library is deliberately small and
is intended to stay that way. So, what should be in and what should be out?
The question is: does this feature gain something by being part of the
standard library which other features that are deliberately excluded (like
left pad) do not?

Repeating a collection endlessly is a useful ability.
>

I don't doubt it. Is your argument that any useful and commonly used
feature should be part of the standard library? That's simply not the
stated criteria for inclusion in the standard library. Hence, why
Foundation exists outside of it. There's no point in debating these
criteria, as (afaict) that's not up for debate. Again, I don't make the
rules. I'm just saying they exist, and I'm arguing that we should abide by
them.


> Yes, it can be written on top of the standard library. It would be
> generally nice not to require that *especially* when we can repeat single
> elements without similar effort. The asymmetry is awkward to remember for
> newbies and awkward to explain away  with "we want a focused library so…
> the Thing A stays but this logically related Thing B can't be in even
> though showing you the ability to do A does tend to lead you to ask after
> Thing B."
>
>
> On Mon, May 1, 2017 at 11:55 PM, Xiaodi Wu  wrote:
>
>> That's a tautological argument, though. By definition, if it's in the
>> standard library, it becomes standardized and discoverable. This isn't at
>> all a limiting principle for what goes into the library and what doesn't.
>>
>> And as I said, there are many commonly useful facilities that aren't part
>> of the standard library, by design and not by oversight. Left pad is one of
>> them.
>>
>> I'm trying to tease out whether this particular proposal meets the
>> current bar for inclusion. If you believe left pad should be included, your
>> beef is with the deliberate choice to have a small standard library, which
>> as far as I know is not up for reconsideration.
>>
>> On Mon, May 1, 2017 at 22:41 T.J. Usiyan  wrote:
>>
>>> This gains discoverability and standardization by being part of the
>>> standard library. New folks would not have to import some library or roll
>>> their own to get this reasonable to expect/hope or hope for functionality.
>>> Perhaps removing the old function isn't going to work but repeating
>>> collections is definitely something useful.
>>>
>>> Left padding for strings would be nice as well, but that is neither here
>>> nor there.
>>>
>>> On Mon, May 1, 2017 at 11:29 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  wrote:

>
> > On 2 May 2017, at 04:44, Xiaodi Wu  wrote:
> >
> > Does this gain something by being part of the standard library as
> opposed to being built on top of it?
>
> Well, somebody thought repeatElement was general enough to make
> part of the standard library. If we’re going to allow repeating a single
> item as a Collection, we might as well allow generalise it to repeating 
> any
> Collection in a loop (including a CollectionOfOne, which is the existing
> use-case).
>

 That doesn't answer the question, though: does the feature you
 propose--repeating any instance of Collection in a loop--gain anything by
 being a part of the standard library rather than an extension to it?

 There are _many_ useful algorithms that can be implemented on top of
 the standard library and can be of general use; nonetheless, they aren't a
 part of the standard library. IIUC, it's not because people just haven't
 had the time to flesh it out; rather, it is a deliberate choice to have a
 small, narrowly focused standard library. The philosophy, as I understand
 it, is to make it convenient for users to roll their own conveniences
 rather than providing all the bits and bobs in the library itself.

 One of the points of differentiation between standard library and
 Foundation is said to be whether something is necessary to support a core
 language feature, in which case it goes into the standard library. As a
 consequence, there are less commonly used parts of the standard library
 which are there because they support other (decidedly not esoteric) parts
 of the standard library and also happen to 

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu via swift-evolution]

On Mon, May 1, 2017 at 11:15 PM, Xiaodi Wu  wrote:

> On Mon, May 1, 2017 at 10:52 PM, Karl Wagner  wrote:
>
>>
>> On 2 May 2017, at 05:29, Xiaodi Wu  wrote:
>>
>> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  wrote:
>>
>>>
>>> > On 2 May 2017, at 04:44, Xiaodi Wu  wrote:
>>> >
>>> > Does this gain something by being part of the standard library as
>>> opposed to being built on top of it?
>>>
>>> Well, somebody thought repeatElement was general enough to make part
>>> of the standard library. If we’re going to allow repeating a single item as
>>> a Collection, we might as well allow generalise it to repeating any
>>> Collection in a loop (including a CollectionOfOne, which is the existing
>>> use-case).
>>>
>>
>> That doesn't answer the question, though: does the feature you
>> propose--repeating any instance of Collection in a loop--gain anything by
>> being a part of the standard library rather than an extension to it?
>>
>> There are _many_ useful algorithms that can be implemented on top of the
>> standard library and can be of general use; nonetheless, they aren't a part
>> of the standard library. IIUC, it's not because people just haven't had the
>> time to flesh it out; rather, it is a deliberate choice to have a small,
>> narrowly focused standard library. The philosophy, as I understand it, is
>> to make it convenient for users to roll their own conveniences rather than
>> providing all the bits and bobs in the library itself.
>>
>> One of the points of differentiation between standard library and
>> Foundation is said to be whether something is necessary to support a core
>> language feature, in which case it goes into the standard library. As a
>> consequence, there are less commonly used parts of the standard library
>> which are there because they support other (decidedly not esoteric) parts
>> of the standard library and also happen to have some plausible public uses.
>> Taking a quick look into the repository, for instance, `repeatElement` is
>> used in the implementation of `UnicodeScalar`. However, just because
>> someone determined that `repeatElement` is worth making a public API (since
>> it's going to be in the standard library whether or not it's public),
>> doesn't _automatically_ mean that a generalization of it should be included
>> in the library as well.
>>
>>
>> This seems contradictory. Either the standard library is small and
>> deliberately focussed; or it isn’t and it’s okay for random "bits and bobs”
>> such as repeatElement to be public just because the standard library
>> arbitrarily uses them somewhere.
>>
>
> I don't see how. The standard library _is_ small--and it's focused, though
> not perhaps on what you think it should be. It's not that only the most
> commonly sought-after features go into the standard library; it's that only
> such features as are necessary to support the core language go into the
> standard library. `repeatElement` isn't randomly part of the library; it's
> used to implement strings.
>
> Either “repeat” functionality (in general) is useful and the generalised
>> behaviour should be in the standard library, or none of it should be.
>>
>
> That doesn't follow at all. It's like saying, either types (in general)
> are useful and higher-kinded types should be supported by Swift, or Swift
> should be untyped.
>
>
>> Personally, I usually want to repeat a collection of things far more
>>> often than I want to repeat an individual thing. It annoys me that the
>>> standard library only provides the one I almost never need.
>>>
>>
>> There are many facilities that the standard library does not provide.
>> Heck, we don't even have left padding for strings! (JavaScript reference,
>> for those following along.) Is there something about this particular
>> feature that makes its not being a part of the standard library uniquely
>> problematic?
>>
>>
>> Additionally, it could help remove the top-level “repeatElement”
>>> function, which I know irritates some people who would rather us not have
>>> any top-level functions in the standard library.
>>>
>>
>> With source stability as a goal, the bar for removal isn't "irritates
>> some people." I actively use this function and there's no justification at
>> all for breaking it.
>>
>> Frankly, I cannot see removal of top-level functions simply because they
>> are top-level to be in scope essentially ever. So let's subset that out of
>> this discussion.
>>
>>
>> Again, this seems contradictory given your comments just a few lines up
>> about how spartan the stdlib is supposed to be. Why do you insist that this
>> single-purpose function remain,
>>
>
> *I'm* not inventing the source stability criteria here. It's been made
> very clear that the bar for removing something existing the language now is
> very high and not at all based on whether it would be included in the first
> place if it were proposed today. There 

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[T.J. Usiyan via swift-evolution]

Xi: "Does this gain something by being part of the standard library?"
Me: "This gains discoverability and standardization by being part of the
standard library."
Xi: "By definition, if it's in the standard library, it becomes
standardized and discoverable."

We're in agreement, then?

Repeating a collection endlessly is a useful ability. Yes, it can be
written on top of the standard library. It would be generally nice not to
require that *especially* when we can repeat single elements without
similar effort. The asymmetry is awkward to remember for newbies and
awkward to explain away  with "we want a focused library so… the Thing A
stays but this logically related Thing B can't be in even though showing
you the ability to do A does tend to lead you to ask after Thing B."


On Mon, May 1, 2017 at 11:55 PM, Xiaodi Wu  wrote:

> That's a tautological argument, though. By definition, if it's in the
> standard library, it becomes standardized and discoverable. This isn't at
> all a limiting principle for what goes into the library and what doesn't.
>
> And as I said, there are many commonly useful facilities that aren't part
> of the standard library, by design and not by oversight. Left pad is one of
> them.
>
> I'm trying to tease out whether this particular proposal meets the current
> bar for inclusion. If you believe left pad should be included, your beef is
> with the deliberate choice to have a small standard library, which as far
> as I know is not up for reconsideration.
>
> On Mon, May 1, 2017 at 22:41 T.J. Usiyan  wrote:
>
>> This gains discoverability and standardization by being part of the
>> standard library. New folks would not have to import some library or roll
>> their own to get this reasonable to expect/hope or hope for functionality.
>> Perhaps removing the old function isn't going to work but repeating
>> collections is definitely something useful.
>>
>> Left padding for strings would be nice as well, but that is neither here
>> nor there.
>>
>> On Mon, May 1, 2017 at 11:29 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  wrote:
>>>

 > On 2 May 2017, at 04:44, Xiaodi Wu  wrote:
 >
 > Does this gain something by being part of the standard library as
 opposed to being built on top of it?

 Well, somebody thought repeatElement was general enough to make part
 of the standard library. If we’re going to allow repeating a single item as
 a Collection, we might as well allow generalise it to repeating any
 Collection in a loop (including a CollectionOfOne, which is the existing
 use-case).

>>>
>>> That doesn't answer the question, though: does the feature you
>>> propose--repeating any instance of Collection in a loop--gain anything by
>>> being a part of the standard library rather than an extension to it?
>>>
>>> There are _many_ useful algorithms that can be implemented on top of the
>>> standard library and can be of general use; nonetheless, they aren't a part
>>> of the standard library. IIUC, it's not because people just haven't had the
>>> time to flesh it out; rather, it is a deliberate choice to have a small,
>>> narrowly focused standard library. The philosophy, as I understand it, is
>>> to make it convenient for users to roll their own conveniences rather than
>>> providing all the bits and bobs in the library itself.
>>>
>>> One of the points of differentiation between standard library and
>>> Foundation is said to be whether something is necessary to support a core
>>> language feature, in which case it goes into the standard library. As a
>>> consequence, there are less commonly used parts of the standard library
>>> which are there because they support other (decidedly not esoteric) parts
>>> of the standard library and also happen to have some plausible public uses.
>>> Taking a quick look into the repository, for instance, `repeatElement` is
>>> used in the implementation of `UnicodeScalar`. However, just because
>>> someone determined that `repeatElement` is worth making a public API (since
>>> it's going to be in the standard library whether or not it's public),
>>> doesn't _automatically_ mean that a generalization of it should be included
>>> in the library as well.
>>>
>>> Personally, I usually want to repeat a collection of things far more
 often than I want to repeat an individual thing. It annoys me that the
 standard library only provides the one I almost never need.

>>>
>>> There are many facilities that the standard library does not provide.
>>> Heck, we don't even have left padding for strings! (JavaScript reference,
>>> for those following along.) Is there something about this particular
>>> feature that makes its not being a part of the standard library uniquely
>>> problematic?
>>>
>>> Additionally, it could help remove the top-level 

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu via swift-evolution]

On Mon, May 1, 2017 at 10:52 PM, Karl Wagner  wrote:

>
> On 2 May 2017, at 05:29, Xiaodi Wu  wrote:
>
> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  wrote:
>
>>
>> > On 2 May 2017, at 04:44, Xiaodi Wu  wrote:
>> >
>> > Does this gain something by being part of the standard library as
>> opposed to being built on top of it?
>>
>> Well, somebody thought repeatElement was general enough to make part
>> of the standard library. If we’re going to allow repeating a single item as
>> a Collection, we might as well allow generalise it to repeating any
>> Collection in a loop (including a CollectionOfOne, which is the existing
>> use-case).
>>
>
> That doesn't answer the question, though: does the feature you
> propose--repeating any instance of Collection in a loop--gain anything by
> being a part of the standard library rather than an extension to it?
>
> There are _many_ useful algorithms that can be implemented on top of the
> standard library and can be of general use; nonetheless, they aren't a part
> of the standard library. IIUC, it's not because people just haven't had the
> time to flesh it out; rather, it is a deliberate choice to have a small,
> narrowly focused standard library. The philosophy, as I understand it, is
> to make it convenient for users to roll their own conveniences rather than
> providing all the bits and bobs in the library itself.
>
> One of the points of differentiation between standard library and
> Foundation is said to be whether something is necessary to support a core
> language feature, in which case it goes into the standard library. As a
> consequence, there are less commonly used parts of the standard library
> which are there because they support other (decidedly not esoteric) parts
> of the standard library and also happen to have some plausible public uses.
> Taking a quick look into the repository, for instance, `repeatElement` is
> used in the implementation of `UnicodeScalar`. However, just because
> someone determined that `repeatElement` is worth making a public API (since
> it's going to be in the standard library whether or not it's public),
> doesn't _automatically_ mean that a generalization of it should be included
> in the library as well.
>
>
> This seems contradictory. Either the standard library is small and
> deliberately focussed; or it isn’t and it’s okay for random "bits and bobs”
> such as repeatElement to be public just because the standard library
> arbitrarily uses them somewhere.
>

I don't see how. The standard library _is_ small--and it's focused, though
not perhaps on what you think it should be. It's not that only the most
commonly sought-after features go into the standard library; it's that only
such features as are necessary to support the core language go into the
standard library. `repeatElement` isn't randomly part of the library; it's
used to implement strings.

Either “repeat” functionality (in general) is useful and the generalised
> behaviour should be in the standard library, or none of it should be.
>

That doesn't follow at all. It's like saying, either types (in general) are
useful and higher-kinded types should be supported by Swift, or Swift
should be untyped.


> Personally, I usually want to repeat a collection of things far more often
>> than I want to repeat an individual thing. It annoys me that the standard
>> library only provides the one I almost never need.
>>
>
> There are many facilities that the standard library does not provide.
> Heck, we don't even have left padding for strings! (JavaScript reference,
> for those following along.) Is there something about this particular
> feature that makes its not being a part of the standard library uniquely
> problematic?
>
>
> Additionally, it could help remove the top-level “repeatElement” function,
>> which I know irritates some people who would rather us not have any
>> top-level functions in the standard library.
>>
>
> With source stability as a goal, the bar for removal isn't "irritates some
> people." I actively use this function and there's no justification at all
> for breaking it.
>
> Frankly, I cannot see removal of top-level functions simply because they
> are top-level to be in scope essentially ever. So let's subset that out of
> this discussion.
>
>
> Again, this seems contradictory given your comments just a few lines up
> about how spartan the stdlib is supposed to be. Why do you insist that this
> single-purpose function remain,
>

*I'm* not inventing the source stability criteria here. It's been made very
clear that the bar for removing something existing the language now is very
high and not at all based on whether it would be included in the first
place if it were proposed today. There have been several criteria laid out
for such source-breaking changes, and "irritates some people" doesn't meet
that bar. In insisting on preserving source stability, I'm only insisting
that 

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu via swift-evolution]

That's a tautological argument, though. By definition, if it's in the
standard library, it becomes standardized and discoverable. This isn't at
all a limiting principle for what goes into the library and what doesn't.

And as I said, there are many commonly useful facilities that aren't part
of the standard library, by design and not by oversight. Left pad is one of
them.

I'm trying to tease out whether this particular proposal meets the current
bar for inclusion. If you believe left pad should be included, your beef is
with the deliberate choice to have a small standard library, which as far
as I know is not up for reconsideration.
On Mon, May 1, 2017 at 22:41 T.J. Usiyan  wrote:

> This gains discoverability and standardization by being part of the
> standard library. New folks would not have to import some library or roll
> their own to get this reasonable to expect/hope or hope for functionality.
> Perhaps removing the old function isn't going to work but repeating
> collections is definitely something useful.
>
> Left padding for strings would be nice as well, but that is neither here
> nor there.
>
> On Mon, May 1, 2017 at 11:29 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  wrote:
>>
>>>
>>> > On 2 May 2017, at 04:44, Xiaodi Wu  wrote:
>>> >
>>> > Does this gain something by being part of the standard library as
>>> opposed to being built on top of it?
>>>
>>> Well, somebody thought repeatElement was general enough to make part
>>> of the standard library. If we’re going to allow repeating a single item as
>>> a Collection, we might as well allow generalise it to repeating any
>>> Collection in a loop (including a CollectionOfOne, which is the existing
>>> use-case).
>>>
>>
>> That doesn't answer the question, though: does the feature you
>> propose--repeating any instance of Collection in a loop--gain anything by
>> being a part of the standard library rather than an extension to it?
>>
>> There are _many_ useful algorithms that can be implemented on top of the
>> standard library and can be of general use; nonetheless, they aren't a part
>> of the standard library. IIUC, it's not because people just haven't had the
>> time to flesh it out; rather, it is a deliberate choice to have a small,
>> narrowly focused standard library. The philosophy, as I understand it, is
>> to make it convenient for users to roll their own conveniences rather than
>> providing all the bits and bobs in the library itself.
>>
>> One of the points of differentiation between standard library and
>> Foundation is said to be whether something is necessary to support a core
>> language feature, in which case it goes into the standard library. As a
>> consequence, there are less commonly used parts of the standard library
>> which are there because they support other (decidedly not esoteric) parts
>> of the standard library and also happen to have some plausible public uses.
>> Taking a quick look into the repository, for instance, `repeatElement` is
>> used in the implementation of `UnicodeScalar`. However, just because
>> someone determined that `repeatElement` is worth making a public API (since
>> it's going to be in the standard library whether or not it's public),
>> doesn't _automatically_ mean that a generalization of it should be included
>> in the library as well.
>>
>> Personally, I usually want to repeat a collection of things far more
>>> often than I want to repeat an individual thing. It annoys me that the
>>> standard library only provides the one I almost never need.
>>>
>>
>> There are many facilities that the standard library does not provide.
>> Heck, we don't even have left padding for strings! (JavaScript reference,
>> for those following along.) Is there something about this particular
>> feature that makes its not being a part of the standard library uniquely
>> problematic?
>>
>> Additionally, it could help remove the top-level “repeatElement”
>>> function, which I know irritates some people who would rather us not have
>>> any top-level functions in the standard library.
>>>
>>
>> With source stability as a goal, the bar for removal isn't "irritates
>> some people." I actively use this function and there's no justification at
>> all for breaking it. Frankly, I cannot see removal of top-level functions
>> simply because they are top-level to be in scope essentially ever. So let's
>> subset that out of this discussion.
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Karl Wagner via swift-evolution]

> On 2 May 2017, at 05:29, Xiaodi Wu  wrote:
> 
> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  > wrote:
> 
> > On 2 May 2017, at 04:44, Xiaodi Wu  > > wrote:
> >
> > Does this gain something by being part of the standard library as opposed 
> > to being built on top of it?
> 
> Well, somebody thought repeatElement was general enough to make part of 
> the standard library. If we’re going to allow repeating a single item as a 
> Collection, we might as well allow generalise it to repeating any Collection 
> in a loop (including a CollectionOfOne, which is the existing use-case).
> 
> That doesn't answer the question, though: does the feature you 
> propose--repeating any instance of Collection in a loop--gain anything by 
> being a part of the standard library rather than an extension to it?
> 
> There are _many_ useful algorithms that can be implemented on top of the 
> standard library and can be of general use; nonetheless, they aren't a part 
> of the standard library. IIUC, it's not because people just haven't had the 
> time to flesh it out; rather, it is a deliberate choice to have a small, 
> narrowly focused standard library. The philosophy, as I understand it, is to 
> make it convenient for users to roll their own conveniences rather than 
> providing all the bits and bobs in the library itself.
> 
> One of the points of differentiation between standard library and Foundation 
> is said to be whether something is necessary to support a core language 
> feature, in which case it goes into the standard library. As a consequence, 
> there are less commonly used parts of the standard library which are there 
> because they support other (decidedly not esoteric) parts of the standard 
> library and also happen to have some plausible public uses. Taking a quick 
> look into the repository, for instance, `repeatElement` is used in the 
> implementation of `UnicodeScalar`. However, just because someone determined 
> that `repeatElement` is worth making a public API (since it's going to be in 
> the standard library whether or not it's public), doesn't _automatically_ 
> mean that a generalization of it should be included in the library as well.

This seems contradictory. Either the standard library is small and deliberately 
focussed; or it isn’t and it’s okay for random "bits and bobs” such as 
repeatElement to be public just because the standard library arbitrarily uses 
them somewhere.

Either “repeat” functionality (in general) is useful and the generalised 
behaviour should be in the standard library, or none of it should be. 

> 
> Personally, I usually want to repeat a collection of things far more often 
> than I want to repeat an individual thing. It annoys me that the standard 
> library only provides the one I almost never need.
> 
> There are many facilities that the standard library does not provide. Heck, 
> we don't even have left padding for strings! (JavaScript reference, for those 
> following along.) Is there something about this particular feature that makes 
> its not being a part of the standard library uniquely problematic?
> 
> Additionally, it could help remove the top-level “repeatElement” function, 
> which I know irritates some people who would rather us not have any top-level 
> functions in the standard library.
> 
> With source stability as a goal, the bar for removal isn't "irritates some 
> people." I actively use this function and there's no justification at all for 
> breaking it.
> Frankly, I cannot see removal of top-level functions simply because they are 
> top-level to be in scope essentially ever. So let's subset that out of this 
> discussion.
> 


Again, this seems contradictory given your comments just a few lines up about 
how spartan the stdlib is supposed to be. Why do you insist that this 
single-purpose function remain, and the more broadly-useful, generalised 
functionality cannot possibly be a fit for the standard library? It seems that 
the reverse is more likely to be true.

As I said, I personally don’t care about what happens to the top-level 
function. This is only a pitch, so I wanted to hear from those people who 
really do want to remove them all before writing up a full proposal.

- Karl


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

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[T.J. Usiyan via swift-evolution]

This gains discoverability and standardization by being part of the
standard library. New folks would not have to import some library or roll
their own to get this reasonable to expect/hope or hope for functionality.
Perhaps removing the old function isn't going to work but repeating
collections is definitely something useful.

Left padding for strings would be nice as well, but that is neither here
nor there.

On Mon, May 1, 2017 at 11:29 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  wrote:
>
>>
>> > On 2 May 2017, at 04:44, Xiaodi Wu  wrote:
>> >
>> > Does this gain something by being part of the standard library as
>> opposed to being built on top of it?
>>
>> Well, somebody thought repeatElement was general enough to make part
>> of the standard library. If we’re going to allow repeating a single item as
>> a Collection, we might as well allow generalise it to repeating any
>> Collection in a loop (including a CollectionOfOne, which is the existing
>> use-case).
>>
>
> That doesn't answer the question, though: does the feature you
> propose--repeating any instance of Collection in a loop--gain anything by
> being a part of the standard library rather than an extension to it?
>
> There are _many_ useful algorithms that can be implemented on top of the
> standard library and can be of general use; nonetheless, they aren't a part
> of the standard library. IIUC, it's not because people just haven't had the
> time to flesh it out; rather, it is a deliberate choice to have a small,
> narrowly focused standard library. The philosophy, as I understand it, is
> to make it convenient for users to roll their own conveniences rather than
> providing all the bits and bobs in the library itself.
>
> One of the points of differentiation between standard library and
> Foundation is said to be whether something is necessary to support a core
> language feature, in which case it goes into the standard library. As a
> consequence, there are less commonly used parts of the standard library
> which are there because they support other (decidedly not esoteric) parts
> of the standard library and also happen to have some plausible public uses.
> Taking a quick look into the repository, for instance, `repeatElement` is
> used in the implementation of `UnicodeScalar`. However, just because
> someone determined that `repeatElement` is worth making a public API (since
> it's going to be in the standard library whether or not it's public),
> doesn't _automatically_ mean that a generalization of it should be included
> in the library as well.
>
> Personally, I usually want to repeat a collection of things far more often
>> than I want to repeat an individual thing. It annoys me that the standard
>> library only provides the one I almost never need.
>>
>
> There are many facilities that the standard library does not provide.
> Heck, we don't even have left padding for strings! (JavaScript reference,
> for those following along.) Is there something about this particular
> feature that makes its not being a part of the standard library uniquely
> problematic?
>
> Additionally, it could help remove the top-level “repeatElement” function,
>> which I know irritates some people who would rather us not have any
>> top-level functions in the standard library.
>>
>
> With source stability as a goal, the bar for removal isn't "irritates some
> people." I actively use this function and there's no justification at all
> for breaking it. Frankly, I cannot see removal of top-level functions
> simply because they are top-level to be in scope essentially ever. So let's
> subset that out of this discussion.
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu via swift-evolution]

On Mon, May 1, 2017 at 9:52 PM, Karl Wagner  wrote:

>
> > On 2 May 2017, at 04:44, Xiaodi Wu  wrote:
> >
> > Does this gain something by being part of the standard library as
> opposed to being built on top of it?
>
> Well, somebody thought repeatElement was general enough to make part of
> the standard library. If we’re going to allow repeating a single item as a
> Collection, we might as well allow generalise it to repeating any
> Collection in a loop (including a CollectionOfOne, which is the existing
> use-case).
>

That doesn't answer the question, though: does the feature you
propose--repeating any instance of Collection in a loop--gain anything by
being a part of the standard library rather than an extension to it?

There are _many_ useful algorithms that can be implemented on top of the
standard library and can be of general use; nonetheless, they aren't a part
of the standard library. IIUC, it's not because people just haven't had the
time to flesh it out; rather, it is a deliberate choice to have a small,
narrowly focused standard library. The philosophy, as I understand it, is
to make it convenient for users to roll their own conveniences rather than
providing all the bits and bobs in the library itself.

One of the points of differentiation between standard library and
Foundation is said to be whether something is necessary to support a core
language feature, in which case it goes into the standard library. As a
consequence, there are less commonly used parts of the standard library
which are there because they support other (decidedly not esoteric) parts
of the standard library and also happen to have some plausible public uses.
Taking a quick look into the repository, for instance, `repeatElement` is
used in the implementation of `UnicodeScalar`. However, just because
someone determined that `repeatElement` is worth making a public API (since
it's going to be in the standard library whether or not it's public),
doesn't _automatically_ mean that a generalization of it should be included
in the library as well.

Personally, I usually want to repeat a collection of things far more often
> than I want to repeat an individual thing. It annoys me that the standard
> library only provides the one I almost never need.
>

There are many facilities that the standard library does not provide. Heck,
we don't even have left padding for strings! (JavaScript reference, for
those following along.) Is there something about this particular feature
that makes its not being a part of the standard library uniquely
problematic?

Additionally, it could help remove the top-level “repeatElement” function,
> which I know irritates some people who would rather us not have any
> top-level functions in the standard library.
>

With source stability as a goal, the bar for removal isn't "irritates some
people." I actively use this function and there's no justification at all
for breaking it. Frankly, I cannot see removal of top-level functions
simply because they are top-level to be in scope essentially ever. So let's
subset that out of this discussion.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Karl Wagner via swift-evolution]

> On 2 May 2017, at 04:44, Xiaodi Wu  wrote:
> 
> Does this gain something by being part of the standard library as opposed to 
> being built on top of it?

Well, somebody thought repeatElement was general enough to make part of the 
standard library. If we’re going to allow repeating a single item as a 
Collection, we might as well allow generalise it to repeating any Collection in 
a loop (including a CollectionOfOne, which is the existing use-case).

Personally, I usually want to repeat a collection of things far more often than 
I want to repeat an individual thing. It annoys me that the standard library 
only provides the one I almost never need.

Additionally, it could help remove the top-level “repeatElement” function, 
which I know irritates some people who would rather us not have any top-level 
functions in the standard library.

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

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

[Xiaodi Wu via swift-evolution]

Does this gain something by being part of the standard library as opposed
to being built on top of it?

On Mon, May 1, 2017 at 21:34 Karl Wagner via swift-evolution <
swift-evolution@swift.org> wrote:

> Currently, we have the Repeated type, which presents a single element
> as though it were a Collection.
>
> > for i in repeatElement(1, count: 3) { print(i) }
> 1
> 1
> 1
>
> > for i in repeatElement([1, 2, 3], count: 3) { print(i) }
> [1, 2, 3]
> [1, 2, 3]
> [1, 2, 3]
>
>
> However, we lack the ability for Collections to repeat their contents in a
> single list; basically, some kind of “flatMap” to repeatElement’s “map”. So
> I’d like to pitch a new API for repeated values.
>
> - We would add a RepeatCollection type, which loops over
> its base Collection a certain number of times (or until a maximum ‘count’).
>   Implementation might look something like this (
> https://gist.github.com/karwa/5228974a0b4dfd000a916f0aac2721c6), except
> that we’d add some optimised map(), filter() and contains() functions which
> apply the algorithm once to the base and multiply the result.
>
> - We would add 3 new functions to all Collections:
>
> /// Repeats the collection *itself* N times.
> ///
> func repeated(_ times: Int) -> RepeatCollection
>
> /// Repeats the collection’s *contents* N times.
> ///
> func repeatElements(_ times: Int) -> RepeatCollection
>
> /// Loops the collection’s contents to present a Collection of length N.
> ///
> func repeatElements(count: Int) -> RepeatCollection
>
>
> - We would replace the existing Repeated type with a typealias to
> RepeatCollection
> - The existing, top-level repeatElement(T, Int) function *could* stay,
> but could also be replaced with an incantation on CollectionOfOne. I’m
> fairly ambivalent about this point - it’d be nice to see the function go,
> but the replacement also isn’t obvious.
>
> Example usage of the new API:
>
> // Equivalent to repeatElement(1, count: 3)
>
> > for i in CollectionOfOne(1).repeatElements(3).forEach { print(i) }
> 1
> 1
> 1
>
> // Equivalent to repeatElement([1, 2, 3], count: 3)
>
> > for i in [1, 2, 3].repeated(3).forEach { print(i) }
> [1, 2, 3]
> [1, 2, 3]
> [1, 2, 3]
>
> // New, flat repetition
>
> > for i in [1, 2, 3].repeatElements(3) { print(i) }
> 1
> 2
> 3
> 1
> 2
> 3
> 1
> 2
> 3
>
> // New, flat repetition
>
> > for i in [1, 2, 3].repeatElements(count: 4) { print(i) }
> 1
> 2
> 3
> 1
>
> // Additional benefit: you can now repeat slices!
>
> > String(“yellow”.characters.dropFirst().dropLast().repeat(times: 3))
> “elloelloello"
>
>
> Thoughts?
>
> - Karl
>
> ___
> 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] [Pitch] New collection-based 'repeat' API

[Karl Wagner via swift-evolution]

Currently, we have the Repeated type, which presents a single element as 
though it were a Collection. 

> for i in repeatElement(1, count: 3) { print(i) }
1
1
1

> for i in repeatElement([1, 2, 3], count: 3) { print(i) }
[1, 2, 3]
[1, 2, 3]
[1, 2, 3]

However, we lack the ability for Collections to repeat their contents in a 
single list; basically, some kind of “flatMap” to repeatElement’s “map”. So I’d 
like to pitch a new API for repeated values. 

- We would add a RepeatCollection type, which loops over its 
base Collection a certain number of times (or until a maximum ‘count’). 
  Implementation might look something like this 
(https://gist.github.com/karwa/5228974a0b4dfd000a916f0aac2721c6), except that 
we’d add some optimised map(), filter() and contains() functions which apply 
the algorithm once to the base and multiply the result.

- We would add 3 new functions to all Collections:

/// Repeats the collection itself N times.
///
func repeated(_ times: Int) -> RepeatCollection

/// Repeats the collection’s contents N times.
///
func repeatElements(_ times: Int) -> RepeatCollection

/// Loops the collection’s contents to present a Collection of length N.
///
func repeatElements(count: Int) -> RepeatCollection

- We would replace the existing Repeated type with a typealias to 
RepeatCollection
- The existing, top-level repeatElement(T, Int) function could stay, but could 
also be replaced with an incantation on CollectionOfOne. I’m fairly ambivalent 
about this point - it’d be nice to see the function go, but the replacement 
also isn’t obvious.

Example usage of the new API:

// Equivalent to repeatElement(1, count: 3)

> for i in CollectionOfOne(1).repeatElements(3).forEach { print(i) }
1
1
1

// Equivalent to repeatElement([1, 2, 3], count: 3)

> for i in [1, 2, 3].repeated(3).forEach { print(i) }
[1, 2, 3]
[1, 2, 3]
[1, 2, 3]

// New, flat repetition

> for i in [1, 2, 3].repeatElements(3) { print(i) }
1
2
3
1
2
3
1
2
3

// New, flat repetition

> for i in [1, 2, 3].repeatElements(count: 4) { print(i) }
1
2
3
1

// Additional benefit: you can now repeat slices!

> String(“yellow”.characters.dropFirst().dropLast().repeat(times: 3))
“elloelloello"


Thoughts?

- Karl

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Xiaodi Wu via swift-evolution]

Howard, this is also mentioned in the generics manifesto under "Opening
existentials," and it's received plentiful discussion and will surely
receive more as these issues become addressed in future proposals. Let's
not divert the conversation here about map and filter.
On Mon, May 1, 2017 at 19:36 Howard Lovatt  wrote:

> Yes, I know the change I suggested involves making generalised
> existentials. I am suggesting not making *any* changes until such effort
> is available. I understand that this would be after Swift 4. I think the
> wait would be worthwhile.
>
> As an aside: Currently one of the big issues with generalised existentials
> in Swift is with Self (which you can think of as a form of generic
> argument). Currently:
>
> protocol Equatable {
> static func ==(lhs: Self, rhs: Self) -> Bool
> ...
> }
> struct Int: Equatable { ... }
> let e1: Equatable = 1
> let e2: Equatable = 2
> if e1 == e2 { ... } // error: e1 and e2 don't necessarily have the
> same dynamic type
>
> I would replace this with:
>
> protocol Equatable { // Use T instead of Self
> static func ==(lhs: T, rhs: T) -> Bool
> ...
> }
> struct Int: Equatable { ... }
> let e1: Equatable = 1
> let e2: Equatable = 2
> if e1 == e2 { ... } // No longer an error since they are both
> Equatable
>
> As an aside on the aside, even better:
>
> protocol Equatable { // T defaults to Self
> static func ==(lhs: T, rhs: T) -> Bool
> ...
> }
> struct Int: Equatable { ... } // T is Int, the default is Self
> let e1: Equatable = 1  // T is Int, the default is Self
> let e2: Equatable = 2 // T is Int, the default is Self
> if e1 == e2 { ... } // No longer an error since they are both
> Equatable
>
> Everything I am suggesting is done in other languages and from my personal
> experience works out better.
>
>
>   -- Howard.
>
> On 2 May 2017 at 09:53, Xiaodi Wu  wrote:
>
>> Howard, take a look at the generics manifesto section on generic
>> protocols:
>>
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
>>
>> It explains very nicely how what you're really asking for is not generic
>> protocols but generalized existentials. This would be nice to have, but
>> it's clearly not happening within the next month and it wouldn't change the
>> solution for filter, for which this proposal is the obvious fix.
>>
>> On Mon, May 1, 2017 at 18:09 Howard Lovatt via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> review of SE-0174 "Change `filter` to return an associated type"
>>>
>>>
>>>- What is your evaluation of the proposal?
>>>
>>> I think a change in this 'area' is valuable because currently always
>>> returning an array from collection operations is limiting. However I think
>>> this proposal feels like 'papering' over problems rather than fixing the
>>> root cause. I think it would be better to reject this and do two more
>>> adventurous proposals instead:
>>>
>>>   1. Allow protocols to be generic, instead of associated types, so that
>>> you can write Sequence
>>>   2. Allow Self to accept a generic argument, so that you can write
>>> Self
>>>
>>> With these to, admittedly much more major changes, you can then write:
>>>
>>> protocol Sequence {
>>> func filter(_ isIncluded: (T) throws -> Bool) rethrows ->
>>> Sequence
>>> func map(_ mapper: (T) throws -> M) rethrows -> Sequence
>>> }
>>> extension RangeReplaceableCollection {
>>> func filter(_ isIncluded: (T) throws -> Bool) rethrows ->
>>> Self {
>>> var result = Self()
>>> for element in self {
>>> if try isIncluded(element) {
>>>  result.append(element)
>>> }
>>> }
>>>return result
>>> }
>>> func map(_ mapper: (T) throws -> M) rethrows -> Self {
>>> var result = Self()
>>> for element in self {
>>> try result.append(mapper(element))
>>> }
>>>return result
>>> }
>>> }
>>>
>>> Which I think both reads better and is more powerful since it allows map
>>> to be written also.
>>>
>>>
>>>- Is the problem being addressed significant enough to warrant a
>>>change to Swift?
>>>
>>> Yes, return an array is a real pain
>>>
>>>
>>>- Does this proposal fit well with the feel and direction of Swift?
>>>
>>> Yes and no, really smacks of papering over other flaws. Might box Swift
>>> into a corner were other problems can't be fixed because the underlying,
>>> real, problems still remain.
>>>
>>>
>>>- If you have used other languages or libraries with a similar
>>>feature, how do you feel that this proposal compares to those?
>>>
>>> Virtually all other languages I have used, e.g. Java, Scala, use the
>>> solution I presented above.
>>>
>>>
>>>- How much effort did you put into 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Howard Lovatt via swift-evolution]

Yes, I know the change I suggested involves making generalised existentials.
I am suggesting not making *any* changes until such effort is available. I
understand that this would be after Swift 4. I think the wait would be
worthwhile.

As an aside: Currently one of the big issues with generalised existentials
in Swift is with Self (which you can think of as a form of generic
argument). Currently:

protocol Equatable {
static func ==(lhs: Self, rhs: Self) -> Bool
...
}
struct Int: Equatable { ... }
let e1: Equatable = 1
let e2: Equatable = 2
if e1 == e2 { ... } // error: e1 and e2 don't necessarily have the same
dynamic type

I would replace this with:

protocol Equatable { // Use T instead of Self
static func ==(lhs: T, rhs: T) -> Bool
...
}
struct Int: Equatable { ... }
let e1: Equatable = 1
let e2: Equatable = 2
if e1 == e2 { ... } // No longer an error since they are both
Equatable

As an aside on the aside, even better:

protocol Equatable { // T defaults to Self
static func ==(lhs: T, rhs: T) -> Bool
...
}
struct Int: Equatable { ... } // T is Int, the default is Self
let e1: Equatable = 1  // T is Int, the default is Self
let e2: Equatable = 2 // T is Int, the default is Self
if e1 == e2 { ... } // No longer an error since they are both
Equatable

Everything I am suggesting is done in other languages and from my personal
experience works out better.


  -- Howard.

On 2 May 2017 at 09:53, Xiaodi Wu  wrote:

> Howard, take a look at the generics manifesto section on generic protocols:
>
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
>
> It explains very nicely how what you're really asking for is not generic
> protocols but generalized existentials. This would be nice to have, but
> it's clearly not happening within the next month and it wouldn't change the
> solution for filter, for which this proposal is the obvious fix.
>
> On Mon, May 1, 2017 at 18:09 Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> review of SE-0174 "Change `filter` to return an associated type"
>>
>>
>>- What is your evaluation of the proposal?
>>
>> I think a change in this 'area' is valuable because currently always
>> returning an array from collection operations is limiting. However I think
>> this proposal feels like 'papering' over problems rather than fixing the
>> root cause. I think it would be better to reject this and do two more
>> adventurous proposals instead:
>>
>>   1. Allow protocols to be generic, instead of associated types, so that
>> you can write Sequence
>>   2. Allow Self to accept a generic argument, so that you can write
>> Self
>>
>> With these to, admittedly much more major changes, you can then write:
>>
>> protocol Sequence {
>> func filter(_ isIncluded: (T) throws -> Bool) rethrows ->
>> Sequence
>> func map(_ mapper: (T) throws -> M) rethrows -> Sequence
>> }
>> extension RangeReplaceableCollection {
>> func filter(_ isIncluded: (T) throws -> Bool) rethrows -> Self
>>  {
>> var result = Self()
>> for element in self {
>> if try isIncluded(element) {
>>  result.append(element)
>> }
>> }
>>return result
>> }
>> func map(_ mapper: (T) throws -> M) rethrows -> Self {
>> var result = Self()
>> for element in self {
>> try result.append(mapper(element))
>> }
>>return result
>> }
>> }
>>
>> Which I think both reads better and is more powerful since it allows map
>> to be written also.
>>
>>
>>- Is the problem being addressed significant enough to warrant a
>>change to Swift?
>>
>> Yes, return an array is a real pain
>>
>>
>>- Does this proposal fit well with the feel and direction of Swift?
>>
>> Yes and no, really smacks of papering over other flaws. Might box Swift
>> into a corner were other problems can't be fixed because the underlying,
>> real, problems still remain.
>>
>>
>>- If you have used other languages or libraries with a similar
>>feature, how do you feel that this proposal compares to those?
>>
>> Virtually all other languages I have used, e.g. Java, Scala, use the
>> solution I presented above.
>>
>>
>>- How much effort did you put into your review? A glance, a quick
>>reading, or an in-depth study?
>>
>> Have been bitten by this and have written my own collection hierarchy to
>> overcome this limitation, and others, of the current library.
>>
>> -- Howard.
>>
>> On 29 Apr 2017, at 10:06 am, Douglas Gregor  wrote:
>>
>> Hello Swift community,
>>
>> The review of SE-0174 "Change `filter` to return an associated type"
>> begins now and runs through May 3, 2017. The proposal is available here:
>>
>> 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[T.J. Usiyan via swift-evolution]

I think that `Either` in the standard library with some means to provide
generalized behavior for two-cased enums would be an amazing salve for
this. Handling errors thrown in Playgrounds is one of the best examples, in
my opinion, of why we need something like Either/Result in the standard
library. It is fairly unpleasant to work with throwing code in a
playground. I end up creating a `Result` type to standardize and sweeten
throwing, for one.

On Mon, May 1, 2017 at 5:48 PM, Rod Brown via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On 2 May 2017, at 2:34 am, John McCall  wrote:
>
>
> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution <
> swift-evolution@swift.org> wrote:
> I agree that the key problem with the current architecture that you're
> alluding to is it can't be easily *stored and transferred. *Swift errors
> are great for live action but holding and passing after the throwing event
> is problematic, and this is an elegant solution. The storage issue is
> when holding it as a property, and the transferring issue is when passing
> it to a closure as a results of an asynchronous operation etc. These are
> both definitely cases where storage of the type-or-error makes perfect
> sense.
>
> I think the key problem getting this accepted by the Swift Team will be
> that it doesn't currently have any specific use in the standard library. As
> a low level set of types, errors are generated by the lower levels but
> rarely stored, so the Standard library doesn't need the storage. Generally
> the only place we have to do that is in end user code. And currently the
> standard library doesn't have to support asynchronous operations natively,
> so there's nothing inside the kit that would require it to do completion
> handlers with errors.
>
>
> We've definitely considered including a Result type, but our sense was
> that in an ideal world almost no code would be using it.  It's hard to
> imagine an ordinary API that ought to be returning a Result rather than
> throwing, and once you've defined that away, the major remaining use case
> is just to shift computation around, like with a completion handler.  That
> explicit computation-shifting pattern is something we're hoping to largely
> define away with something like C#'s async/await, which would leave Result
> as mostly just an implementation detail of such APIs.  We didn't want to
> spend a great deal of time designing a type that would end up being so
> marginal, especially if the changing role would lead us into different
> directions on the design itself.  We also didn't want to design a type that
> would become an obstacle to potential future language changes like, say,
> typed throws.
>
> The downside, of course, is that as long as we lack that async/await
> design, computation-shifting isn't real great.
>
> John.
>
>
> This makes sense and is sensible. I’m curious how such an API would play
> with the existing NSURLSession completion handlers and the like, but I’m
> sure the community can design something appropriate.
>
> I think the only remaining case is simply storing a result-or-error for
> later handling, storage to disk, etc. I agree with your contention that the
> vast majority of the use case for this type is for computation shifting. I
> think it would and should be rare that we would want to “store” as a
> variable the “result-or-error” type. Errors should be handled at runtime in
> the vast majority of cases, presented to the user or otherwise handled, and
> then moved on from, with the reason no longer being relevant.
>
> As you say, in the meantime, it does leave computation-shifting a bit
> ad-hoc and convoluted, but I think the community has standardized on the
> Result temporary solution.
>
>
>
> This would therefore be an element in the standard library purely so we
> don't have 50,000 different libraries with 50,000 different result types.
> I'd love to see this standardised so frameworks were more compatible. I'm
> just not sure whether the Core Team would see it as pressing to try and
> officiate a certain type that they themselves don't use.
>
>
>
> ___
> 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] [Review] SE-0174: Change `filter` to return an associated type

[T.J. Usiyan via swift-evolution]

+1

There are many things that I would like more but this is a reasonable
compromise.



On Mon, May 1, 2017 at 8:02 PM, Nevin Brackett-Rozinsky via swift-evolution
 wrote:

> Another possibility is to make “map” generic on the return type, something
> like:
>
> extension Collection {
> func map (transform: (Iterator.Element)
> throws -> T.Iterator.Element) rethrows -> T {
> var result = T()
> for e in self { try result.append(transform(e)) }
> return result
> }
> }
>
> That way the user can choose what type they want. And since there is also
> a more-specific implementation returning an Array, that is what you’ll get
> if context does not constrain the type, so existing code will still work
> the same.
>
> We could do the same for “filter”, in which case the current proposal
> would just change what the default type is. So…what I’m talking about here
> would be purely additive and can happen later.
>
> In any case, I do like the idea being proposed in SE–0174. If I have a
> collection and I filter it down, it makes sense to still be the same kind
> of collection. So, +1 from me.
>
> Nevin
>
> ___
> 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] [Review] SE-0174: Change `filter` to return an associated type

[Nevin Brackett-Rozinsky via swift-evolution]

Another possibility is to make “map” generic on the return type, something
like:

extension Collection {
func map (transform: (Iterator.Element)
throws -> T.Iterator.Element) rethrows -> T {
var result = T()
for e in self { try result.append(transform(e)) }
return result
}
}

That way the user can choose what type they want. And since there is also a
more-specific implementation returning an Array, that is what you’ll get if
context does not constrain the type, so existing code will still work the
same.

We could do the same for “filter”, in which case the current proposal would
just change what the default type is. So…what I’m talking about here would
be purely additive and can happen later.

In any case, I do like the idea being proposed in SE–0174. If I have a
collection and I filter it down, it makes sense to still be the same kind
of collection. So, +1 from me.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Xiaodi Wu via swift-evolution]

Howard, take a look at the generics manifesto section on generic protocols:

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

It explains very nicely how what you're really asking for is not generic
protocols but generalized existentials. This would be nice to have, but
it's clearly not happening within the next month and it wouldn't change the
solution for filter, for which this proposal is the obvious fix.

On Mon, May 1, 2017 at 18:09 Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> review of SE-0174 "Change `filter` to return an associated type"
>
>
>- What is your evaluation of the proposal?
>
> I think a change in this 'area' is valuable because currently always
> returning an array from collection operations is limiting. However I think
> this proposal feels like 'papering' over problems rather than fixing the
> root cause. I think it would be better to reject this and do two more
> adventurous proposals instead:
>
>   1. Allow protocols to be generic, instead of associated types, so that
> you can write Sequence
>   2. Allow Self to accept a generic argument, so that you can write Self
>
> With these to, admittedly much more major changes, you can then write:
>
> protocol Sequence {
> func filter(_ isIncluded: (T) throws -> Bool) rethrows ->
> Sequence
> func map(_ mapper: (T) throws -> M) rethrows -> Sequence
> }
> extension RangeReplaceableCollection {
> func filter(_ isIncluded: (T) throws -> Bool) rethrows -> Self
>  {
> var result = Self()
> for element in self {
> if try isIncluded(element) {
>  result.append(element)
> }
> }
>return result
> }
> func map(_ mapper: (T) throws -> M) rethrows -> Self {
> var result = Self()
> for element in self {
> try result.append(mapper(element))
> }
>return result
> }
> }
>
> Which I think both reads better and is more powerful since it allows map
> to be written also.
>
>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Yes, return an array is a real pain
>
>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes and no, really smacks of papering over other flaws. Might box Swift
> into a corner were other problems can't be fixed because the underlying,
> real, problems still remain.
>
>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> Virtually all other languages I have used, e.g. Java, Scala, use the
> solution I presented above.
>
>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> Have been bitten by this and have written my own collection hierarchy to
> overcome this limitation, and others, of the current library.
>
> -- Howard.
>
> On 29 Apr 2017, at 10:06 am, Douglas Gregor  wrote:
>
> Hello Swift community,
>
> The review of SE-0174 "Change `filter` to return an associated type"
> begins now and runs through May 3, 2017. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md
>
> Reply text
>
> Other replies
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug Gregor
>
> Review Manager
>
> ___
> swift-evolution-announce mailing list

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Howard Lovatt via swift-evolution]

> review of SE-0174 "Change `filter` to return an associated type" 
> 
> What is your evaluation of the proposal?
I think a change in this 'area' is valuable because currently always returning 
an array from collection operations is limiting. However I think this proposal 
feels like 'papering' over problems rather than fixing the root cause. I think 
it would be better to reject this and do two more adventurous proposals instead:

  1. Allow protocols to be generic, instead of associated types, so that you 
can write Sequence
  2. Allow Self to accept a generic argument, so that you can write Self

With these to, admittedly much more major changes, you can then write:

protocol Sequence {
func filter(_ isIncluded: (T) throws -> Bool) rethrows -> Sequence
func map(_ mapper: (T) throws -> M) rethrows -> Sequence
}
extension RangeReplaceableCollection {
func filter(_ isIncluded: (T) throws -> Bool) rethrows -> Self { 
var result = Self() 
for element in self { 
if try isIncluded(element) { 
 result.append(element) 
}
} 
   return result 
} 
func map(_ mapper: (T) throws -> M) rethrows -> Self { 
var result = Self() 
for element in self { 
try result.append(mapper(element))
} 
   return result 
} 
}

Which I think both reads better and is more powerful since it allows map to be 
written also.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, return an array is a real pain

> Does this proposal fit well with the feel and direction of Swift?
Yes and no, really smacks of papering over other flaws. Might box Swift into a 
corner were other problems can't be fixed because the underlying, real, 
problems still remain.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Virtually all other languages I have used, e.g. Java, Scala, use the solution I 
presented above. 

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Have been bitten by this and have written my own collection hierarchy to 
overcome this limitation, and others, of the current library. 

-- Howard.

> On 29 Apr 2017, at 10:06 am, Douglas Gregor  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0174 "Change `filter` to return an associated type" begins 
> now and runs through May 3, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

[Martin Waitz via swift-evolution]

Hello,

Many of the listed package managers are for interpreted languages.
So after fetching all dependencies, your package is completely usable. It is 
„installed locally“.
But Swift packages have to be compiled. You have to build them to be able to 
use them.
For me, ‚install' comes after compilation, not before.

Using ‚resolve‘ is thus a much better name for the proposed command.
The verb ‚install‘ should only be used when it really installs the package in 
some way.

— 
Martin
 
> Am 01.05.2017 um 00:46 schrieb Jon Shier via swift-evolution 
> :
> 
>   `install` only sounds like it should install things in the system if 
> that’s the only type of manager you’ve ever used. If I’ve only ever used 
> brew, of course I’ll assume that every other thing that calls itself a 
> package manager will operate similarly. Thankfully, people learn quickly and 
> it’s pretty easy to tell the difference between project package managers and 
> system package mangers. Pretty much anyone developing on Apple platforms will 
> be familiar with brew and CocoaPods  / bundler, all of which use the 
> `install` verb, so following those would be an easy way to gain immediate 
> familiarity. SPM really shouldn't be too different given that it will have to 
> interoperate on systems with these tools, so choosing your own verbs would be 
> far more confusing than using `install`. Carthage’s use of `bootstrap` is 
> weird outlier that is always confusing to me. Plus, using `install`, allows 
> you to use `.installed` for the file, which I think makes more sense than 
> `.lock` or `.resolved`.
>   A second issue is that `resolve` doesn’t sound like it installs 
> anything at all. It sounds like a command that would just print the resolved 
> versions of all my dependencies but do nothing else. 
> 
> 
> 
> Jon
> 
> 
>> On Apr 30, 2017, at 12:06 AM, Rick Ballard via swift-evolution 
>> > wrote:
>> 
>> Thanks for the feedback, David, and apologies for the slow reply. My biggest 
>> reservation with the word "install" is that it really sounds like it should 
>> install things into the system, or another shareable location, instead of 
>> fetching dependencies into the dependency location for a single top-level 
>> package. We might actually want to add a real "install" command that does 
>> some type of installation some day in the future, though we might also 
>> choose to forever leave that sort of thing to your system package manager. 
>> And while there is some precedence for other package managers using 
>> "install" to fetch dependencies, I think there's broader precedence for it 
>> meaning to either install things into the system, or at least create an 
>> installable "build root", with e.g. `make install`, `xcodebuild install`, 
>> `brew install`, etc.
>> 
>> I just did a quick survey of the same package managers I surveyed previously 
>> to see if they all used this term, and here's what I found:
>> 
>> yarn: `install`
>> composer: `install`
>> cargo: No true equivalent, just supprts `update` or `build`. Also, uses 
>> `install` to mean something different – `cargo install` installs binary 
>> packages only, to a installation root.
>> bundler: `install`
>> cocoapods: `install`
>> glide: `install`
>> pub: `get`
>> mix: `deps.get`
>> rebar3: `get-deps`
>> carton: `install`
>> carthage: `bootstrap`
>> pip: Uses `install`, but since pip doesn't enforce the top-level-package 
>> seperation of SwiftPM, Pip's use of `install` is actually more accurate.
>> npm: `install`
>> meteor: no true equivalent, just supports `update` or `build`
>> 
>> Given that this isn't a universal term, I think I'm comfortable going 
>> against the flow a little bit if it means that we get to have clear and 
>> accurate command-line verbs. But I think this is worth adding to the 
>> "Alternatives Considered" section before we put this up for review!
>> 
>>  - Rick

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

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Rod Brown via swift-evolution]

> On 2 May 2017, at 2:34 am, John McCall  wrote:
> 
>> 
>> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution 
>> > wrote:
>> I agree that the key problem with the current architecture that you're 
>> alluding to is it can't be easily stored and transferred. Swift errors are 
>> great for live action but holding and passing after the throwing event is 
>> problematic, and this is an elegant solution. The storage issue is when 
>> holding it as a property, and the transferring issue is when passing it to a 
>> closure as a results of an asynchronous operation etc. These are both 
>> definitely cases where storage of the type-or-error makes perfect sense.
>> 
>> I think the key problem getting this accepted by the Swift Team will be that 
>> it doesn't currently have any specific use in the standard library. As a low 
>> level set of types, errors are generated by the lower levels but rarely 
>> stored, so the Standard library doesn't need the storage. Generally the only 
>> place we have to do that is in end user code. And currently the standard 
>> library doesn't have to support asynchronous operations natively, so there's 
>> nothing inside the kit that would require it to do completion handlers with 
>> errors.
> 
> We've definitely considered including a Result type, but our sense was that 
> in an ideal world almost no code would be using it.  It's hard to imagine an 
> ordinary API that ought to be returning a Result rather than throwing, and 
> once you've defined that away, the major remaining use case is just to shift 
> computation around, like with a completion handler.  That explicit 
> computation-shifting pattern is something we're hoping to largely define away 
> with something like C#'s async/await, which would leave Result as mostly just 
> an implementation detail of such APIs.  We didn't want to spend a great deal 
> of time designing a type that would end up being so marginal, especially if 
> the changing role would lead us into different directions on the design 
> itself.  We also didn't want to design a type that would become an obstacle 
> to potential future language changes like, say, typed throws.
> 
> The downside, of course, is that as long as we lack that async/await design, 
> computation-shifting isn't real great.
> 
> John.

This makes sense and is sensible. I’m curious how such an API would play with 
the existing NSURLSession completion handlers and the like, but I’m sure the 
community can design something appropriate.

I think the only remaining case is simply storing a result-or-error for later 
handling, storage to disk, etc. I agree with your contention that the vast 
majority of the use case for this type is for computation shifting. I think it 
would and should be rare that we would want to “store” as a variable the 
“result-or-error” type. Errors should be handled at runtime in the vast 
majority of cases, presented to the user or otherwise handled, and then moved 
on from, with the reason no longer being relevant.

As you say, in the meantime, it does leave computation-shifting a bit ad-hoc 
and convoluted, but I think the community has standardized on the Result 
temporary solution.

> 
>> 
>> This would therefore be an element in the standard library purely so we 
>> don't have 50,000 different libraries with 50,000 different result types. 
>> I'd love to see this standardised so frameworks were more compatible. I'm 
>> just not sure whether the Core Team would see it as pressing to try and 
>> officiate a certain type that they themselves don't use.

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

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Itai Ferber via swift-evolution]

If you need multiple different representations for multiple different 
formats, then yes, you will likely want to supply different `CodingKeys` 
enums for those formats and write a custom encode which switches on the 
format you're writing to. Or, you can use one `CodingKeys` enum which 
has multiple different key representations (for the different formats 
you want to support) and use that.


Automatic key renaming is an inherently unsafe operation, so it's not 
something that we want to provide out of the box, or encourage, but it 
should be possible if you really want it.


On 1 May 2017, at 13:04, Anders Ha wrote:

I do mean optional automatic translation on the encoders’ and 
decoders’ end though. Derived conformances from other common naming 
conventions are nice to have, but does not help if one wants to define 
a model that can be decoded from and encoded into different coded 
representations of itself. It also “hardwired" the model with a 
specific coding scheme, which does not seem very nice from an 
encapsulation PoV.


That said I am fairly sure there would be third party libraries 
providing key mapping/transformation, if Foundation’s encoders and 
decoders do not provide such functionality. So it is probably not a 
big deal.


Regards
Anders


On 2 May 2017, at 3:06 AM, Itai Ferber  wrote:

Sorry, one clarifying statement: it's not the JSON encoder and 
decoder that will be providing this renaming (since they should be 
encoding the key values they are given as-is); the key names are part 
of the definition of the enum, as declared as part of the type.


On 1 May 2017, at 12:04, Itai Ferber via swift-evolution wrote:

Yes, this should be true for most types.
The compiler derives conformance based on a nested CodingKeys type 
within your Codable type. If you do not supply one, it will derive 
one on your behalf, but if you do provide one, making a naming 
transition like this is trivial:


public struct Post
 : Codable {

let authorID: Int


let authorName: String


let bodyText: String



private enum CodingKeys: String
, CodingKey {

case authorID = "author_id"


case authorName = "author_name"


case bodyText = "body_text"

}


// init(from:) and encode(to:) are still automatically generated

}

This is something we wanted to explicitly support as we don't want 
users to have to violate Swift naming guidelines, and is a step along 
the progressive disclosure of the API that we want to provide.
As long as the case names of the enum match 1-to-1 with property 
names, derived conformance still applies.


On 1 May 2017, at 11:39, Anders Ha wrote:


I thought it would be quite trivial to have the JSON encoder and 
decoder transforming the keys between camel case and snake case, 
wouldn't it?



Regards
Anders

On 2 May 2017, at 1:57 AM, Jon Shier via swift-evolution 
 wrote:


	FYI, I’d give the derived implementations a very low chance of 
ever being used for JSON. Unless developers violate the Swift naming 
guidelines for their properties at least or they don’t have 
properties with multiword keys.
	Once this functionality has landed for the Swift 4 branch, I plan 
to implement some of the tricky JSON types I had to decode on a 
recent project, just to see how painful the custom syntax will be, 
and to compare it to my existing Argo implementation. Hopefully 
there will be time for at least one round of feedback to be 
integrated into this functionality.




Jon


On May 1, 2017, at 12:54 PM, Itai Ferber via swift-evolution 
 wrote:


Hi Goffredo,

On Apr 26, 2017, at 2:00 PM, Goffredo Marocchi  
wrote:


Hello Itai,

Sorry for the confusion, but I understood that the following

To answer your second question, the reason is that using the 
protocol implies that all encoders and decoders must support 
anything that conforms to that protocol. We’re not sure this is 
a reasonable requirement. Many formats do not have any kind of 
support for arbitrary size integers, for example. Therefore, we 
felt it was best to limit it to a set of concrete types.


meant it would actually hinder that kind of transformation or make 
it more difficult to write custom decoders and encoders. Sorry if 
I misunderstood that.


One follow up question: what would happen if inside the JSON mock 
object you posted I were to remove the 'address' key (in terms of 
the produced object and how to access its inner properties)?


What would happen if I remove the 'name' one or better if I add 
another key to the JSON object?
Codable conformance is derived by default to require that all 
non-optional properties be initialized. This means that if you have 
a non-optional property address: Address but there is no address 
key in the JSON payload you're decoding from, it will throw an 
error to indicate that the key was not found.
On the flip side, if the JSON payload has information in it which 
your type does not have (e.g. if there 

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Anders Ha via swift-evolution]

I do mean optional automatic translation on the encoders’ and decoders’ end 
though. Derived conformances from other common naming conventions are nice to 
have, but does not help if one wants to define a model that can be decoded from 
and encoded into different coded representations of itself. It also “hardwired" 
the model with a specific coding scheme, which does not seem very nice from an 
encapsulation PoV.

That said I am fairly sure there would be third party libraries providing key 
mapping/transformation, if Foundation’s encoders and decoders do not provide 
such functionality. So it is probably not a big deal.

Regards
Anders

> On 2 May 2017, at 3:06 AM, Itai Ferber  wrote:
> 
> Sorry, one clarifying statement: it's not the JSON encoder and decoder that 
> will be providing this renaming (since they should be encoding the key values 
> they are given as-is); the key names are part of the definition of the enum, 
> as declared as part of the type.
> 
> On 1 May 2017, at 12:04, Itai Ferber via swift-evolution wrote:
> 
> Yes, this should be true for most types.
> The compiler derives conformance based on a nested CodingKeys type within 
> your Codable type. If you do not supply one, it will derive one on your 
> behalf, but if you do provide one, making a naming transition like this is 
> trivial:
> 
> public struct Post
>  : Codable {
> 
> let authorID: Int
> 
> 
> let authorName: String
> 
> 
> let bodyText: String
> 
> 
> 
> private enum CodingKeys: String
> , CodingKey {
> 
> case authorID = "author_id"
> 
> 
> case authorName = "author_name"
> 
> 
> case bodyText = "body_text"
> 
> }
> 
> 
> // init(from:) and encode(to:) are still automatically generated
> 
> }
> 
> This is something we wanted to explicitly support as we don't want users to 
> have to violate Swift naming guidelines, and is a step along the progressive 
> disclosure of the API that we want to provide.
> As long as the case names of the enum match 1-to-1 with property names, 
> derived conformance still applies.
> 
> On 1 May 2017, at 11:39, Anders Ha wrote:
> 
> 
> I thought it would be quite trivial to have the JSON encoder and decoder 
> transforming the keys between camel case and snake case, wouldn't it?
> 
> 
> Regards
> Anders
> 
>> On 2 May 2017, at 1:57 AM, Jon Shier via swift-evolution 
>>  wrote:
>> 
>>  FYI, I’d give the derived implementations a very low chance of ever 
>> being used for JSON. Unless developers violate the Swift naming guidelines 
>> for their properties at least or they don’t have properties with multiword 
>> keys.
>>  Once this functionality has landed for the Swift 4 branch, I plan to 
>> implement some of the tricky JSON types I had to decode on a recent project, 
>> just to see how painful the custom syntax will be, and to compare it to my 
>> existing Argo implementation. Hopefully there will be time for at least one 
>> round of feedback to be integrated into this functionality.
>> 
>> 
>> 
>> Jon
>> 
>> 
>>> On May 1, 2017, at 12:54 PM, Itai Ferber via swift-evolution 
>>>  wrote:
>>> 
>>> Hi Goffredo,
>>> 
 On Apr 26, 2017, at 2:00 PM, Goffredo Marocchi  wrote:
 
 Hello Itai,
 
 Sorry for the confusion, but I understood that the following
 
> To answer your second question, the reason is that using the protocol 
> implies that all encoders and decoders must support anything that 
> conforms to that protocol. We’re not sure this is a reasonable 
> requirement. Many formats do not have any kind of support for arbitrary 
> size integers, for example. Therefore, we felt it was best to limit it to 
> a set of concrete types.
 
 meant it would actually hinder that kind of transformation or make it more 
 difficult to write custom decoders and encoders. Sorry if I misunderstood 
 that.
 
 One follow up question: what would happen if inside the JSON mock object 
 you posted I were to remove the 'address' key (in terms of the produced 
 object and how to access its inner properties)? 
 
 What would happen if I remove the 'name' one or better if I add another 
 key to the JSON object?
>>> Codable conformance is derived by default to require that all non-optional 
>>> properties be initialized. This means that if you have a non-optional 
>>> property address: Address but there is no address key in the JSON payload 
>>> you're decoding from, it will throw an error to indicate that the key was 
>>> not found.
>>> On the flip side, if the JSON payload has information in it which your type 
>>> does not have (e.g. if there is an address in the JSON, but your Person 
>>> just has name), the extra data is ignored.
>>> 
>>> This, however, is just in the default, derived conformance. For more 
>>> complex cases, you can always provide your own init(from:) and 
>>> 

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Itai Ferber via swift-evolution]

Sorry, one clarifying statement:  it's not the JSON encoder and decoder 
that will be providing this renaming (since they should be encoding the 
key values they are given as-is); the key names are part of the 
definition of the enum, as declared as part of the type.


On 1 May 2017, at 12:04, Itai Ferber via swift-evolution wrote:


Yes, this should be true for most types.
The compiler derives conformance based on a nested `CodingKeys` type 
within your `Codable` type. If you do not supply one, it will derive 
one on your behalf, but if you do provide one, making a naming 
transition like this is trivial:


```swift
public struct Post : Codable {
let authorID: Int
let authorName: String
let bodyText: String

private enum CodingKeys: String, CodingKey {
case authorID = "author_id"
case authorName = "author_name"
case bodyText = "body_text"
}

// init(from:) and encode(to:) are still automatically generated
}
```

This is something we wanted to explicitly support as we don't want 
users to have to violate Swift naming guidelines, and is a step along 
the progressive disclosure of the API that we want to provide.
As long as the case names of the enum match 1-to-1 with property 
names, derived conformance still applies.


On 1 May 2017, at 11:39, Anders Ha wrote:

I thought it would be quite trivial to have the JSON encoder and 
decoder transforming the keys between camel case and snake case, 
wouldn't it?



Regards
Anders


On 2 May 2017, at 1:57 AM, Jon Shier via swift-evolution 
 wrote:


	FYI, I’d give the derived implementations a very low chance of 
ever being used for JSON. Unless developers violate the Swift naming 
guidelines for their properties at least or they don’t have 
properties with multiword keys.
	Once this functionality has landed for the Swift 4 branch, I plan 
to implement some of the tricky JSON types I had to decode on a 
recent project, just to see how painful the custom syntax will be, 
and to compare it to my existing Argo implementation. Hopefully 
there will be time for at least one round of feedback to be 
integrated into this functionality.




Jon


On May 1, 2017, at 12:54 PM, Itai Ferber via swift-evolution 
> 
wrote:


Hi Goffredo,

On Apr 26, 2017, at 2:00 PM, Goffredo Marocchi > wrote:


Hello Itai,

Sorry for the confusion, but I understood that the following

To answer your second question, the reason is that using the 
protocol implies that all encoders and decoders must support 
anything that conforms to that protocol. We’re not sure this is 
a reasonable requirement. Many formats do not have any kind of 
support for arbitrary size integers, for example. Therefore, we 
felt it was best to limit it to a set of concrete types.


meant it would actually hinder that kind of transformation or make 
it more difficult to write custom decoders and encoders. Sorry if 
I misunderstood that.


One follow up question: what would happen if inside the JSON mock 
object you posted I were to remove the 'address' key (in terms of 
the produced object and how to access its inner properties)?


What would happen if I remove the 'name' one or better if I add 
another key to the JSON object?
Codable conformance is derived by default to require that all 
non-optional properties be initialized. This means that if you have 
a non-optional property address: Address but there is no address 
key in the JSON payload you're decoding from, it will throw an 
error to indicate that the key was not found.
On the flip side, if the JSON payload has information in it which 
your type does not have (e.g. if there is an address in the JSON, 
but your Person just has name), the extra data is ignored.


This, however, is just in the default, derived conformance. For 
more complex cases, you can always provide your own init(from:) and 
encode(to:)to do custom decoding. If you have a property which may 
or may not be in the JSON, you can always decodeIfPresent, which 
will return nil if the key or value was not found.
If you need to access sub-objects in the JSON data which do not map 
to your properties 1-to-1, e.g. your payload looks like {"name": 
"John Doe", "address": { "street": "1 Infinite Loop", ... } }, but 
your type looks like

struct Person {
let name: String
let street: String
let city: String
// ...
}
then you can always access the nested data by requesting a 
nestedContainer(keyedBy: ..., forKey: .address) which will return a 
container wrapping the address sub-object, which you can then pull 
fields out of.


The derived conformance case gives a reasonable default, but you 
can always write your own init(from:) and encode(to:) to handle 
custom needs.




Sent from my iPhone

On 26 Apr 2017, at 21:28, Itai Ferber > wrote:



Hi Goffredo,

Unless I'm 

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Itai Ferber via swift-evolution]

Yes, this should be true for most types.
The compiler derives conformance based on a nested `CodingKeys` type 
within your `Codable` type. If you do not supply one, it will derive one 
on your behalf, but if you do provide one, making a naming transition 
like this is trivial:


```swift
public struct Post : Codable {
let authorID: Int
let authorName: String
let bodyText: String

private enum CodingKeys: String, CodingKey {
case authorID = "author_id"
case authorName = "author_name"
case bodyText = "body_text"
}

// init(from:) and encode(to:) are still automatically generated
}
```

This is something we wanted to explicitly support as we don't want users 
to have to violate Swift naming guidelines, and is a step along the 
progressive disclosure of the API that we want to provide.
As long as the case names of the enum match 1-to-1 with property names, 
derived conformance still applies.


On 1 May 2017, at 11:39, Anders Ha wrote:

I thought it would be quite trivial to have the JSON encoder and 
decoder transforming the keys between camel case and snake case, 
wouldn't it?



Regards
Anders


On 2 May 2017, at 1:57 AM, Jon Shier via swift-evolution 
 wrote:


	FYI, I’d give the derived implementations a very low chance of 
ever being used for JSON. Unless developers violate the Swift naming 
guidelines for their properties at least or they don’t have 
properties with multiword keys.
	Once this functionality has landed for the Swift 4 branch, I plan to 
implement some of the tricky JSON types I had to decode on a recent 
project, just to see how painful the custom syntax will be, and to 
compare it to my existing Argo implementation. Hopefully there will 
be time for at least one round of feedback to be integrated into this 
functionality.




Jon


On May 1, 2017, at 12:54 PM, Itai Ferber via swift-evolution 
> 
wrote:


Hi Goffredo,

On Apr 26, 2017, at 2:00 PM, Goffredo Marocchi > wrote:


Hello Itai,

Sorry for the confusion, but I understood that the following

To answer your second question, the reason is that using the 
protocol implies that all encoders and decoders must support 
anything that conforms to that protocol. We’re not sure this is 
a reasonable requirement. Many formats do not have any kind of 
support for arbitrary size integers, for example. Therefore, we 
felt it was best to limit it to a set of concrete types.


meant it would actually hinder that kind of transformation or make 
it more difficult to write custom decoders and encoders. Sorry if I 
misunderstood that.


One follow up question: what would happen if inside the JSON mock 
object you posted I were to remove the 'address' key (in terms of 
the produced object and how to access its inner properties)?


What would happen if I remove the 'name' one or better if I add 
another key to the JSON object?
Codable conformance is derived by default to require that all 
non-optional properties be initialized. This means that if you have 
a non-optional property address: Address but there is no address key 
in the JSON payload you're decoding from, it will throw an error to 
indicate that the key was not found.
On the flip side, if the JSON payload has information in it which 
your type does not have (e.g. if there is an address in the JSON, 
but your Person just has name), the extra data is ignored.


This, however, is just in the default, derived conformance. For more 
complex cases, you can always provide your own init(from:) and 
encode(to:)to do custom decoding. If you have a property which may 
or may not be in the JSON, you can always decodeIfPresent, which 
will return nil if the key or value was not found.
If you need to access sub-objects in the JSON data which do not map 
to your properties 1-to-1, e.g. your payload looks like {"name": 
"John Doe", "address": { "street": "1 Infinite Loop", ... } }, but 
your type looks like

struct Person {
let name: String
let street: String
let city: String
// ...
}
then you can always access the nested data by requesting a 
nestedContainer(keyedBy: ..., forKey: .address) which will return a 
container wrapping the address sub-object, which you can then pull 
fields out of.


The derived conformance case gives a reasonable default, but you can 
always write your own init(from:) and encode(to:) to handle custom 
needs.




Sent from my iPhone

On 26 Apr 2017, at 21:28, Itai Ferber > wrote:



Hi Goffredo,

Unless I'm misunderstanding what you mean here, this is exactly 
what we're proposing with the API — anything Encodable can 
encode any type that is Encodable as a nested value:


struct Person : Codable {
let name: String
let address: Address
}

struct Address : Codable {
let street: String
let city: String
let state: String
  

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Anders Ha via swift-evolution]

I thought it would be quite trivial to have the JSON encoder and decoder 
transforming the keys between camel case and snake case, wouldn't it?


Regards
Anders


> On 2 May 2017, at 1:57 AM, Jon Shier via swift-evolution 
>  wrote:
> 
>   FYI, I’d give the derived implementations a very low chance of ever 
> being used for JSON. Unless developers violate the Swift naming guidelines 
> for their properties at least or they don’t have properties with multiword 
> keys.
>   Once this functionality has landed for the Swift 4 branch, I plan to 
> implement some of the tricky JSON types I had to decode on a recent project, 
> just to see how painful the custom syntax will be, and to compare it to my 
> existing Argo implementation. Hopefully there will be time for at least one 
> round of feedback to be integrated into this functionality.
> 
> 
> 
> Jon
> 
> 
>> On May 1, 2017, at 12:54 PM, Itai Ferber via swift-evolution 
>> > wrote:
>> 
>> Hi Goffredo,
>> 
>>> On Apr 26, 2017, at 2:00 PM, Goffredo Marocchi >> > wrote:
>>> 
>>> Hello Itai,
>>> 
>>> Sorry for the confusion, but I understood that the following
>>> 
 To answer your second question, the reason is that using the protocol 
 implies that all encoders and decoders must support anything that conforms 
 to that protocol. We’re not sure this is a reasonable requirement. Many 
 formats do not have any kind of support for arbitrary size integers, for 
 example. Therefore, we felt it was best to limit it to a set of concrete 
 types.
>>> 
>>> meant it would actually hinder that kind of transformation or make it more 
>>> difficult to write custom decoders and encoders. Sorry if I misunderstood 
>>> that.
>>> 
>>> One follow up question: what would happen if inside the JSON mock object 
>>> you posted I were to remove the 'address' key (in terms of the produced 
>>> object and how to access its inner properties)? 
>>> 
>>> What would happen if I remove the 'name' one or better if I add another key 
>>> to the JSON object?
>> Codable conformance is derived by default to require that all non-optional 
>> properties be initialized. This means that if you have a non-optional 
>> property address: Address but there is no address key in the JSON payload 
>> you're decoding from, it will throw an error to indicate that the key was 
>> not found.
>> On the flip side, if the JSON payload has information in it which your type 
>> does not have (e.g. if there is an address in the JSON, but your Person just 
>> has name), the extra data is ignored.
>> 
>> This, however, is just in the default, derived conformance. For more complex 
>> cases, you can always provide your own init(from:) and encode(to:)to do 
>> custom decoding. If you have a property which may or may not be in the JSON, 
>> you can always decodeIfPresent, which will return nil if the key or value 
>> was not found.
>> If you need to access sub-objects in the JSON data which do not map to your 
>> properties 1-to-1, e.g. your payload looks like {"name": "John Doe", 
>> "address": { "street": "1 Infinite Loop", ... } }, but your type looks like
>> struct Person {
>> let name: String
>> let street: String
>> let city: String
>> // ...
>> }
>> then you can always access the nested data by requesting a 
>> nestedContainer(keyedBy: ..., forKey: .address) which will return a 
>> container wrapping the address sub-object, which you can then pull fields 
>> out of.
>> 
>> The derived conformance case gives a reasonable default, but you can always 
>> write your own init(from:) and encode(to:) to handle custom needs.
>> 
>>> 
>>> Sent from my iPhone
>>> 
>>> On 26 Apr 2017, at 21:28, Itai Ferber >> > wrote:
>>> 
 Hi Goffredo,
 
 Unless I'm misunderstanding what you mean here, this is exactly what we're 
 proposing with the API — anything Encodable can encode any type that is 
 Encodable as a nested value:
 
 struct Person : Codable {
 let name: String
 let address: Address
 }
 
 struct Address : Codable {
 let street: String
 let city: String
 let state: String
 let zipCode: Int
 let country: String
 }
 
 let address = Address(street: "1 Infinite Loop", city: "Cupertino", state: 
 "CA", zipCode: 95014, country: "United States")
 let person = Person(name: "John Doe", address: address)
 
 let encoder = JSONEncoder()
 let payload = try encoder.encode(person)
 print(String(data: payload, encoding: .utf8)!) // => {"name": "John Doe", 
 address: {"street": "1 Infinite Loop", ... } }
 
 let decoder = JSONDecoder()
 let decoded = try decoder.decode(Person.self, from: payload) // => 
 Person(name: "John Doe", address: ...)
 Or have I 

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Jon Shier via swift-evolution]

FYI, I’d give the derived implementations a very low chance of ever 
being used for JSON. Unless developers violate the Swift naming guidelines for 
their properties at least or they don’t have properties with multiword keys.
Once this functionality has landed for the Swift 4 branch, I plan to 
implement some of the tricky JSON types I had to decode on a recent project, 
just to see how painful the custom syntax will be, and to compare it to my 
existing Argo implementation. Hopefully there will be time for at least one 
round of feedback to be integrated into this functionality.



Jon


> On May 1, 2017, at 12:54 PM, Itai Ferber via swift-evolution 
>  wrote:
> 
> Hi Goffredo,
> 
>> On Apr 26, 2017, at 2:00 PM, Goffredo Marocchi > > wrote:
>> 
>> Hello Itai,
>> 
>> Sorry for the confusion, but I understood that the following
>> 
>>> To answer your second question, the reason is that using the protocol 
>>> implies that all encoders and decoders must support anything that conforms 
>>> to that protocol. We’re not sure this is a reasonable requirement. Many 
>>> formats do not have any kind of support for arbitrary size integers, for 
>>> example. Therefore, we felt it was best to limit it to a set of concrete 
>>> types.
>> 
>> meant it would actually hinder that kind of transformation or make it more 
>> difficult to write custom decoders and encoders. Sorry if I misunderstood 
>> that.
>> 
>> One follow up question: what would happen if inside the JSON mock object you 
>> posted I were to remove the 'address' key (in terms of the produced object 
>> and how to access its inner properties)? 
>> 
>> What would happen if I remove the 'name' one or better if I add another key 
>> to the JSON object?
> Codable conformance is derived by default to require that all non-optional 
> properties be initialized. This means that if you have a non-optional 
> property address: Address but there is no address key in the JSON payload 
> you're decoding from, it will throw an error to indicate that the key was not 
> found.
> On the flip side, if the JSON payload has information in it which your type 
> does not have (e.g. if there is an address in the JSON, but your Person just 
> has name), the extra data is ignored.
> 
> This, however, is just in the default, derived conformance. For more complex 
> cases, you can always provide your own init(from:) and encode(to:)to do 
> custom decoding. If you have a property which may or may not be in the JSON, 
> you can always decodeIfPresent, which will return nil if the key or value was 
> not found.
> If you need to access sub-objects in the JSON data which do not map to your 
> properties 1-to-1, e.g. your payload looks like {"name": "John Doe", 
> "address": { "street": "1 Infinite Loop", ... } }, but your type looks like
> struct Person {
> let name: String
> let street: String
> let city: String
> // ...
> }
> then you can always access the nested data by requesting a 
> nestedContainer(keyedBy: ..., forKey: .address) which will return a container 
> wrapping the address sub-object, which you can then pull fields out of.
> 
> The derived conformance case gives a reasonable default, but you can always 
> write your own init(from:) and encode(to:) to handle custom needs.
> 
>> 
>> Sent from my iPhone
>> 
>> On 26 Apr 2017, at 21:28, Itai Ferber > > wrote:
>> 
>>> Hi Goffredo,
>>> 
>>> Unless I'm misunderstanding what you mean here, this is exactly what we're 
>>> proposing with the API — anything Encodable can encode any type that is 
>>> Encodable as a nested value:
>>> 
>>> struct Person : Codable {
>>> let name: String
>>> let address: Address
>>> }
>>> 
>>> struct Address : Codable {
>>> let street: String
>>> let city: String
>>> let state: String
>>> let zipCode: Int
>>> let country: String
>>> }
>>> 
>>> let address = Address(street: "1 Infinite Loop", city: "Cupertino", state: 
>>> "CA", zipCode: 95014, country: "United States")
>>> let person = Person(name: "John Doe", address: address)
>>> 
>>> let encoder = JSONEncoder()
>>> let payload = try encoder.encode(person)
>>> print(String(data: payload, encoding: .utf8)!) // => {"name": "John Doe", 
>>> address: {"street": "1 Infinite Loop", ... } }
>>> 
>>> let decoder = JSONDecoder()
>>> let decoded = try decoder.decode(Person.self, from: payload) // => 
>>> Person(name: "John Doe", address: ...)
>>> Or have I misunderstood you?
>>> 
>>> — Itai
>>> 
>>> On 26 Apr 2017, at 13:11, Goffredo Marocchi via swift-evolution wrote:
>>> 
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>> On 26 Apr 2017, at 17:24, Tony Parker via swift-evolution 
>>> > wrote:
>>> 
 Hi Riley,
 
> On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution 
> 

Re: [swift-evolution] [Pitch] Move All Discussions To Github Issues

[Mohamed Ebrahim Afifi via swift-evolution]

Very nice! Thank you!

Best Regards,
Mohamed Afifi

On Mon, May 1, 2017 at 3:50 PM, Muse M  wrote:

> All of your points have been discussed and some of us will prefer
> Discourse to generate mailing format. I remember there is an option for 
> "Mailing
> List mode" in Discourse.
>
> You can trace from this discussion and there were a long separate threads
> few months back which you can trace manually.
> https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170206/031657.html
>
> On Mon, May 1, 2017 at 8:40 PM, Mohamed Ebrahim Afifi via swift-evolution
>  wrote:
>
>> Thanks for your reply! I think that is very good news that the burden of
>> the mailing list is so obvious for everyone!
>>
>> I think Github issues would be better though, the community is used to it
>> and it makes more sense as it needs almost no configurations, no operation
>> costs or maintenance. If the community decided to move to it we can move to
>> it immediately, we don't need to wait. It is a natural next step since the
>> proposals are maintained there and Swift itself is maintained there.
>>
>>
>> Do you have a link to that discussion?
>>
>>
>>
>>
>> Best Regards,
>> Mohamed Afifi
>>
>> On Mon, May 1, 2017 at 1:33 PM, Adrian Zubarev <
>> adrian.zuba...@devandartist.com> wrote:
>>
>>> Hi there,
>>>
>>> you’re a bit too late. A forum will come at some point (Discourse).
>>>
>>> Best regards,
>>>
>>>
>>>
>>> --
>>> Adrian Zubarev
>>> Sent with Airmail
>>>
>>> Am 1. Mai 2017 um 13:30:55, Mohamed Ebrahim Afifi via swift-evolution (
>>> swift-evolution@swift.org) schrieb:
>>>
>>> Hi,
>>>
>>> This is actually not a proposal to improve Swift, it is actually a
>>> proposal to improve the way we use it to improve Swift. :)
>>>
>>> It is extremely hard to monitor discussions going over e-mails.
>>>
>>>1. I always get lost between e-mails especially if there are so many
>>>replies
>>>2. It is extremely hard to reach the original idea/first e-mail.
>>>3. New people (like me) usually get lost between e-mails and only
>>>focus on their own idea and don't care about other's ideas because for
>>>example, I don't know how to reply to an idea if I'm not subscribed to 
>>> the
>>>mailing list. In other words, It’s not a system that encourages follow-up
>>>actions.
>>>4. You can not browse subjects and all replies in one place.
>>>5. You cannot follow a specific topic and ignore others.
>>>
>>> That was the problem!
>>>
>>> My suggestion is to move all discussions from this mailing list to
>>> GitHub issues. For the following reasons.
>>>
>>>1. Easier to browse all topics.
>>>2. You can see open topics and closed topics. So, if a topic is done
>>>we can close it.
>>>3. You can subscribe to a topic and follow all replies and reply.
>>>4. Markdown support. Currently, I see people create a markdown page
>>>on Github and send a link to it on the mailing list. But having the
>>>markdown inline in the topic is a great benefit. Also, replies can be in
>>>markdown as well.
>>>5. It's closer to Proposals (Since we already using Github for
>>>tracking proposals why don't we use it also to track pitching ideas).
>>>People like to have everything gathered together in one place and don't
>>>need to remember the Github repo and mailing list.
>>>6. Github has https://developer.github.com/v3/issues/
>>>
>>>
>>> I think using Github issues instead of the mailing lists will increase
>>> the engagement of the Swift community with proposals.
>>>
>>>
>>> Best Regards,
>>> Mohamed Afifi
>>> ___
>>> 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] [Pitch] Revamp Optional and Throws

[Gor Gyolchanyan via swift-evolution]

I deliberately avoid making any concrete suggestions, because you guys know a 
lot more about internals of Swift then me. I know how to use it (I know how to 
abuse it), but to really come up with the best way to compliment the error 
handling system to make the entire language fluidly work with it in generic and 
protocol contexts would take a real team effort.

> On May 1, 2017, at 7:41 PM, Gor Gyolchanyan  wrote:
> 
> An alternative would be to make throwing error more widely available then 
> just functions.
> What if property getters and setters could throw? That would mean that 
> throwing properties could be passed as parameters that would require the 
> `try` keyword.
> Stored properties could have a new type attribute available (just like `lazy 
> var`, we could have `throws var` or something), which would allow storing the 
> result of a throwing call without `try` and the value of the variable would 
> be only accessible by assigning to another variable with the same attribute 
> or with a `try` keyword.
> I really really like how Swift handles error propagation and the problem is 
> really not that a Result type is missing, but a proper way of spreading the 
> error handling mechanism to a wider range of use cases.
> 
> 
>> On May 1, 2017, at 7:34 PM, John McCall > > wrote:
>> 
>>> 
>>> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution 
>>> > wrote:
>>> 
>>> On 1 May 2017, at 8:16 pm, Gor Gyolchanyan >> > wrote:
>>> 
 Yeah, you’re absolutely right. the “value-or-nil” and 
 “value-or-reason-why-not-value” are two different things and the former is 
 used too liberally in place of the latter because of lack of support.
 In that case, the Result type should not replace the error handling, but 
 augment it. The error handling mechanism is extremely well though-out and 
 convenient for its purpose, but it makes it difficult to capture and store 
 a union of (value; flying error).
>>> 
>>> I agree that the key problem with the current architecture that you're 
>>> alluding to is it can't be easily stored and transferred. Swift errors are 
>>> great for live action but holding and passing after the throwing event is 
>>> problematic, and this is an elegant solution. The storage issue is when 
>>> holding it as a property, and the transferring issue is when passing it to 
>>> a closure as a results of an asynchronous operation etc. These are both 
>>> definitely cases where storage of the type-or-error makes perfect sense.
>>> 
>>> I think the key problem getting this accepted by the Swift Team will be 
>>> that it doesn't currently have any specific use in the standard library. As 
>>> a low level set of types, errors are generated by the lower levels but 
>>> rarely stored, so the Standard library doesn't need the storage. Generally 
>>> the only place we have to do that is in end user code. And currently the 
>>> standard library doesn't have to support asynchronous operations natively, 
>>> so there's nothing inside the kit that would require it to do completion 
>>> handlers with errors.
>> 
>> We've definitely considered including a Result type, but our sense was that 
>> in an ideal world almost no code would be using it.  It's hard to imagine an 
>> ordinary API that ought to be returning a Result rather than throwing, and 
>> once you've defined that away, the major remaining use case is just to shift 
>> computation around, like with a completion handler.  That explicit 
>> computation-shifting pattern is something we're hoping to largely define 
>> away with something like C#'s async/await, which would leave Result as 
>> mostly just an implementation detail of such APIs.  We didn't want to spend 
>> a great deal of time designing a type that would end up being so marginal, 
>> especially if the changing role would lead us into different directions on 
>> the design itself.  We also didn't want to design a type that would become 
>> an obstacle to potential future language changes like, say, typed throws.
>> 
>> The downside, of course, is that as long as we lack that async/await design, 
>> computation-shifting isn't real great.
>> 
>> John.
>> 
>>> 
>>> This would therefore be an element in the standard library purely so we 
>>> don't have 50,000 different libraries with 50,000 different result types. 
>>> I'd love to see this standardised so frameworks were more compatible. I'm 
>>> just not sure whether the Core Team would see it as pressing to try and 
>>> officiate a certain type that they themselves don't use.
>>> 
>>> 
 A built-in Failable enum with syntactic support to losslessly catch it 
 from a throwing expression and unpack it into a throwing scope would be a 
 very useful feature.
 Optionals are extremely convenient, but in cases where the 

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

[Itai Ferber via swift-evolution]

Hi Goffredo,

> On Apr 26, 2017, at 2:00 PM, Goffredo Marocchi  wrote:
> 
> Hello Itai,
> 
> Sorry for the confusion, but I understood that the following
> 
>> To answer your second question, the reason is that using the protocol 
>> implies that all encoders and decoders must support anything that conforms 
>> to that protocol. We’re not sure this is a reasonable requirement. Many 
>> formats do not have any kind of support for arbitrary size integers, for 
>> example. Therefore, we felt it was best to limit it to a set of concrete 
>> types.
> 
> meant it would actually hinder that kind of transformation or make it more 
> difficult to write custom decoders and encoders. Sorry if I misunderstood 
> that.
> 
> One follow up question: what would happen if inside the JSON mock object you 
> posted I were to remove the 'address' key (in terms of the produced object 
> and how to access its inner properties)? 
> 
> What would happen if I remove the 'name' one or better if I add another key 
> to the JSON object?
Codable conformance is derived by default to require that all non-optional 
properties be initialized. This means that if you have a non-optional property 
address: Address but there is no address key in the JSON payload you're 
decoding from, it will throw an error to indicate that the key was not found.
On the flip side, if the JSON payload has information in it which your type 
does not have (e.g. if there is an address in the JSON, but your Person just 
has name), the extra data is ignored.

This, however, is just in the default, derived conformance. For more complex 
cases, you can always provide your own init(from:) and encode(to:) to do custom 
decoding. If you have a property which may or may not be in the JSON, you can 
always decodeIfPresent, which will return nil if the key or value was not found.
If you need to access sub-objects in the JSON data which do not map to your 
properties 1-to-1, e.g. your payload looks like {"name": "John Doe", "address": 
{ "street": "1 Infinite Loop", ... } }, but your type looks like
struct Person {
let name: String
let street: String
let city: String
// ...
}
then you can always access the nested data by requesting a 
nestedContainer(keyedBy: ..., forKey: .address) which will return a container 
wrapping the address sub-object, which you can then pull fields out of.

The derived conformance case gives a reasonable default, but you can always 
write your own init(from:) and encode(to:) to handle custom needs.

> 
> Sent from my iPhone
> 
> On 26 Apr 2017, at 21:28, Itai Ferber  > wrote:
> 
>> Hi Goffredo,
>> 
>> Unless I'm misunderstanding what you mean here, this is exactly what we're 
>> proposing with the API — anything Encodable can encode any type that is 
>> Encodable as a nested value:
>> 
>> struct Person : Codable {
>> let name: String
>> let address: Address
>> }
>> 
>> struct Address : Codable {
>> let street: String
>> let city: String
>> let state: String
>> let zipCode: Int
>> let country: String
>> }
>> 
>> let address = Address(street: "1 Infinite Loop", city: "Cupertino", state: 
>> "CA", zipCode: 95014, country: "United States")
>> let person = Person(name: "John Doe", address: address)
>> 
>> let encoder = JSONEncoder()
>> let payload = try encoder.encode(person)
>> print(String(data: payload, encoding: .utf8)!) // => {"name": "John Doe", 
>> address: {"street": "1 Infinite Loop", ... } }
>> 
>> let decoder = JSONDecoder()
>> let decoded = try decoder.decode(Person.self, from: payload) // => 
>> Person(name: "John Doe", address: ...)
>> Or have I misunderstood you?
>> 
>> — Itai
>> 
>> On 26 Apr 2017, at 13:11, Goffredo Marocchi via swift-evolution wrote:
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On 26 Apr 2017, at 17:24, Tony Parker via swift-evolution 
>> > wrote:
>> 
>>> Hi Riley,
>>> 
 On Apr 25, 2017, at 6:11 PM, Riley Testut via swift-evolution 
 > wrote:
 
 I’m sure this has already been discussed, but why are the methods throwing 
 NSErrors and not Enums? If I’m remembering correctly, the original reason 
 for this was because this was meant to be a part of Foundation. Now that 
 this is in the Standard Library, however, it seems strange that we’re 
 still using NSError.
 
 Second question that again I’m sure was asked and answered already, but: 
 why do we require implementations for each concrete numeric type (Int, 
 Int8, Int16, Float, etc), instead of using protocols (such as the new 
 Integer protocols)?
>>> 
>>> To answer your second question, the reason is that using the protocol 
>>> implies that all encoders and decoders must support anything that conforms 
>>> to that protocol.
>> 
>> Would this make it easier to transform nested JSON 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Gor Gyolchanyan via swift-evolution]

An alternative would be to make throwing error more widely available then just 
functions.
What if property getters and setters could throw? That would mean that throwing 
properties could be passed as parameters that would require the `try` keyword.
Stored properties could have a new type attribute available (just like `lazy 
var`, we could have `throws var` or something), which would allow storing the 
result of a throwing call without `try` and the value of the variable would be 
only accessible by assigning to another variable with the same attribute or 
with a `try` keyword.
I really really like how Swift handles error propagation and the problem is 
really not that a Result type is missing, but a proper way of spreading the 
error handling mechanism to a wider range of use cases.


> On May 1, 2017, at 7:34 PM, John McCall  wrote:
> 
>> 
>> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution 
>> > wrote:
>> 
>> On 1 May 2017, at 8:16 pm, Gor Gyolchanyan > > wrote:
>> 
>>> Yeah, you’re absolutely right. the “value-or-nil” and 
>>> “value-or-reason-why-not-value” are two different things and the former is 
>>> used too liberally in place of the latter because of lack of support.
>>> In that case, the Result type should not replace the error handling, but 
>>> augment it. The error handling mechanism is extremely well though-out and 
>>> convenient for its purpose, but it makes it difficult to capture and store 
>>> a union of (value; flying error).
>> 
>> I agree that the key problem with the current architecture that you're 
>> alluding to is it can't be easily stored and transferred. Swift errors are 
>> great for live action but holding and passing after the throwing event is 
>> problematic, and this is an elegant solution. The storage issue is when 
>> holding it as a property, and the transferring issue is when passing it to a 
>> closure as a results of an asynchronous operation etc. These are both 
>> definitely cases where storage of the type-or-error makes perfect sense.
>> 
>> I think the key problem getting this accepted by the Swift Team will be that 
>> it doesn't currently have any specific use in the standard library. As a low 
>> level set of types, errors are generated by the lower levels but rarely 
>> stored, so the Standard library doesn't need the storage. Generally the only 
>> place we have to do that is in end user code. And currently the standard 
>> library doesn't have to support asynchronous operations natively, so there's 
>> nothing inside the kit that would require it to do completion handlers with 
>> errors.
> 
> We've definitely considered including a Result type, but our sense was that 
> in an ideal world almost no code would be using it.  It's hard to imagine an 
> ordinary API that ought to be returning a Result rather than throwing, and 
> once you've defined that away, the major remaining use case is just to shift 
> computation around, like with a completion handler.  That explicit 
> computation-shifting pattern is something we're hoping to largely define away 
> with something like C#'s async/await, which would leave Result as mostly just 
> an implementation detail of such APIs.  We didn't want to spend a great deal 
> of time designing a type that would end up being so marginal, especially if 
> the changing role would lead us into different directions on the design 
> itself.  We also didn't want to design a type that would become an obstacle 
> to potential future language changes like, say, typed throws.
> 
> The downside, of course, is that as long as we lack that async/await design, 
> computation-shifting isn't real great.
> 
> John.
> 
>> 
>> This would therefore be an element in the standard library purely so we 
>> don't have 50,000 different libraries with 50,000 different result types. 
>> I'd love to see this standardised so frameworks were more compatible. I'm 
>> just not sure whether the Core Team would see it as pressing to try and 
>> officiate a certain type that they themselves don't use.
>> 
>> 
>>> A built-in Failable enum with syntactic support to losslessly catch it from 
>>> a throwing expression and unpack it into a throwing scope would be a very 
>>> useful feature.
>>> Optionals are extremely convenient, but in cases where the Optional is used 
>>> as “value-or-error” rather then “value-or-nil” it falls a bit short and the 
>>> programmer has to choose between extreme convenience of Optionals with the 
>>> downside of lack of error information or the expressive power of throwing 
>>> an error with the downside of a lot of boilerpate and poor integration with 
>>> generics.
>>> Here’s an example pseudo-swift that illustrates this:
>>> 
>>> enum Failable {
>>> 
>>> case success(Wrapped)
>>> 
>>> case failure(Error)
>>> 
>>> }
>>> 
>>> func foo() throws -> Int {
>>> guard 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[John McCall via swift-evolution]

> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution 
>  wrote:
> 
> On 1 May 2017, at 8:16 pm, Gor Gyolchanyan  > wrote:
> 
>> Yeah, you’re absolutely right. the “value-or-nil” and 
>> “value-or-reason-why-not-value” are two different things and the former is 
>> used too liberally in place of the latter because of lack of support.
>> In that case, the Result type should not replace the error handling, but 
>> augment it. The error handling mechanism is extremely well though-out and 
>> convenient for its purpose, but it makes it difficult to capture and store a 
>> union of (value; flying error).
> 
> I agree that the key problem with the current architecture that you're 
> alluding to is it can't be easily stored and transferred. Swift errors are 
> great for live action but holding and passing after the throwing event is 
> problematic, and this is an elegant solution. The storage issue is when 
> holding it as a property, and the transferring issue is when passing it to a 
> closure as a results of an asynchronous operation etc. These are both 
> definitely cases where storage of the type-or-error makes perfect sense.
> 
> I think the key problem getting this accepted by the Swift Team will be that 
> it doesn't currently have any specific use in the standard library. As a low 
> level set of types, errors are generated by the lower levels but rarely 
> stored, so the Standard library doesn't need the storage. Generally the only 
> place we have to do that is in end user code. And currently the standard 
> library doesn't have to support asynchronous operations natively, so there's 
> nothing inside the kit that would require it to do completion handlers with 
> errors.

We've definitely considered including a Result type, but our sense was that in 
an ideal world almost no code would be using it.  It's hard to imagine an 
ordinary API that ought to be returning a Result rather than throwing, and once 
you've defined that away, the major remaining use case is just to shift 
computation around, like with a completion handler.  That explicit 
computation-shifting pattern is something we're hoping to largely define away 
with something like C#'s async/await, which would leave Result as mostly just 
an implementation detail of such APIs.  We didn't want to spend a great deal of 
time designing a type that would end up being so marginal, especially if the 
changing role would lead us into different directions on the design itself.  We 
also didn't want to design a type that would become an obstacle to potential 
future language changes like, say, typed throws.

The downside, of course, is that as long as we lack that async/await design, 
computation-shifting isn't real great.

John.

> 
> This would therefore be an element in the standard library purely so we don't 
> have 50,000 different libraries with 50,000 different result types. I'd love 
> to see this standardised so frameworks were more compatible. I'm just not 
> sure whether the Core Team would see it as pressing to try and officiate a 
> certain type that they themselves don't use.
> 
> 
>> A built-in Failable enum with syntactic support to losslessly catch it from 
>> a throwing expression and unpack it into a throwing scope would be a very 
>> useful feature.
>> Optionals are extremely convenient, but in cases where the Optional is used 
>> as “value-or-error” rather then “value-or-nil” it falls a bit short and the 
>> programmer has to choose between extreme convenience of Optionals with the 
>> downside of lack of error information or the expressive power of throwing an 
>> error with the downside of a lot of boilerpate and poor integration with 
>> generics.
>> Here’s an example pseudo-swift that illustrates this:
>> 
>> enum Failable {
>>  
>>  case success(Wrapped)
>> 
>>  case failure(Error)
>> 
>> }
>> 
>> func foo() throws -> Int {
>>  guard myCondition else {
>>  throw EmbarressingError.oops
>>  }
>>  return 42
>> }
>> 
>> let failable = catch foo() // Failable
>> 
>> func bar() throws -> Int {
>>  throw failable
>> 
>> 
>> 
>>> On May 1, 2017, at 11:17 AM, Rod Brown >> > wrote:
>>> 
>>> The problem I see with your argument is that the core reason why the 
>>> optional cast failed is actually there: It was an optional value, and you 
>>> forced it to unwrap without checking. This is a correct description of the 
>>> error.
>>> 
>>> If we plumbed our code with a tonne of errors saying “why this is optional, 
>>> and why it is null” then we are practically making every optional an error 
>>> in the case of nil, which is completely illogical considering that nil 
>>> could be a completely legitimate case (especially in the case of 
>>> not-implicitly-unwrapped optionals).
>>> 
>>> Optional is a wrapper for "value-or-null", not 

Re: [swift-evolution] [Pitch] Move All Discussions To Github Issues

[Muse M via swift-evolution]

All of your points have been discussed and some of us will prefer Discourse
to generate mailing format. I remember there is an option for "Mailing List
mode" in Discourse.

You can trace from this discussion and there were a long separate threads
few months back which you can trace manually.
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031657.html

On Mon, May 1, 2017 at 8:40 PM, Mohamed Ebrahim Afifi via swift-evolution <
swift-evolution@swift.org> wrote:

> Thanks for your reply! I think that is very good news that the burden of
> the mailing list is so obvious for everyone!
>
> I think Github issues would be better though, the community is used to it
> and it makes more sense as it needs almost no configurations, no operation
> costs or maintenance. If the community decided to move to it we can move to
> it immediately, we don't need to wait. It is a natural next step since the
> proposals are maintained there and Swift itself is maintained there.
>
>
> Do you have a link to that discussion?
>
>
>
>
> Best Regards,
> Mohamed Afifi
>
> On Mon, May 1, 2017 at 1:33 PM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
>> Hi there,
>>
>> you’re a bit too late. A forum will come at some point (Discourse).
>>
>> Best regards,
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 1. Mai 2017 um 13:30:55, Mohamed Ebrahim Afifi via swift-evolution (
>> swift-evolution@swift.org) schrieb:
>>
>> Hi,
>>
>> This is actually not a proposal to improve Swift, it is actually a
>> proposal to improve the way we use it to improve Swift. :)
>>
>> It is extremely hard to monitor discussions going over e-mails.
>>
>>1. I always get lost between e-mails especially if there are so many
>>replies
>>2. It is extremely hard to reach the original idea/first e-mail.
>>3. New people (like me) usually get lost between e-mails and only
>>focus on their own idea and don't care about other's ideas because for
>>example, I don't know how to reply to an idea if I'm not subscribed to the
>>mailing list. In other words, It’s not a system that encourages follow-up
>>actions.
>>4. You can not browse subjects and all replies in one place.
>>5. You cannot follow a specific topic and ignore others.
>>
>> That was the problem!
>>
>> My suggestion is to move all discussions from this mailing list to GitHub
>> issues. For the following reasons.
>>
>>1. Easier to browse all topics.
>>2. You can see open topics and closed topics. So, if a topic is done
>>we can close it.
>>3. You can subscribe to a topic and follow all replies and reply.
>>4. Markdown support. Currently, I see people create a markdown page
>>on Github and send a link to it on the mailing list. But having the
>>markdown inline in the topic is a great benefit. Also, replies can be in
>>markdown as well.
>>5. It's closer to Proposals (Since we already using Github for
>>tracking proposals why don't we use it also to track pitching ideas).
>>People like to have everything gathered together in one place and don't
>>need to remember the Github repo and mailing list.
>>6. Github has https://developer.github.com/v3/issues/
>>
>>
>> I think using Github issues instead of the mailing lists will increase
>> the engagement of the Swift community with proposals.
>>
>>
>> Best Regards,
>> Mohamed Afifi
>> ___
>> 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] [Pitch] Revamp Optional and Throws

[Gor Gyolchanyan via swift-evolution]

One motivation would be the fact that integrating throwing mechanism with this 
Result/Failable type would make error-friendly generics easier, especially the 
infamous `rethrows`.
I think the concept of `rethrows` is a hack that is put there as a quick fix 
for overwhelming complaints about generic boilerplate regarding throwing 
functions.
If the throwing mechanic would be tightly integrated with this idea, 
`rethrowing` would change from a magical feature to a natural side-effect, 
where throwing functions with generic return types would be able to losslessly 
drop the throwing part by changing the return type to a Failable, which would 
propage throughout a chain of generic calls, essentially doing what `rethrows` 
does, but without limitations.
if `try Failable` becomes a thing, then even syntactically, accessing the 
failable result of a generic function would look and feel the same as accessing 
a throwing result of specialized variant of that generic function.

> On May 1, 2017, at 4:01 PM, Rod Brown  wrote:
> 
> On 1 May 2017, at 8:16 pm, Gor Gyolchanyan  > wrote:
> 
>> Yeah, you’re absolutely right. the “value-or-nil” and 
>> “value-or-reason-why-not-value” are two different things and the former is 
>> used too liberally in place of the latter because of lack of support.
>> In that case, the Result type should not replace the error handling, but 
>> augment it. The error handling mechanism is extremely well though-out and 
>> convenient for its purpose, but it makes it difficult to capture and store a 
>> union of (value; flying error).
> 
> I agree that the key problem with the current architecture that you're 
> alluding to is it can't be easily stored and transferred. Swift errors are 
> great for live action but holding and passing after the throwing event is 
> problematic, and this is an elegant solution. The storage issue is when 
> holding it as a property, and the transferring issue is when passing it to a 
> closure as a results of an asynchronous operation etc. These are both 
> definitely cases where storage of the type-or-error makes perfect sense.
> 
> I think the key problem getting this accepted by the Swift Team will be that 
> it doesn't currently have any specific use in the standard library. As a low 
> level set of types, errors are generated by the lower levels but rarely 
> stored, so the Standard library doesn't need the storage. Generally the only 
> place we have to do that is in end user code. And currently the standard 
> library doesn't have to support asynchronous operations natively, so there's 
> nothing inside the kit that would require it to do completion handlers with 
> errors.
> 
> This would therefore be an element in the standard library purely so we don't 
> have 50,000 different libraries with 50,000 different result types. I'd love 
> to see this standardised so frameworks were more compatible. I'm just not 
> sure whether the Core Team would see it as pressing to try and officiate a 
> certain type that they themselves don't use.
> 
> 
>> A built-in Failable enum with syntactic support to losslessly catch it from 
>> a throwing expression and unpack it into a throwing scope would be a very 
>> useful feature.
>> Optionals are extremely convenient, but in cases where the Optional is used 
>> as “value-or-error” rather then “value-or-nil” it falls a bit short and the 
>> programmer has to choose between extreme convenience of Optionals with the 
>> downside of lack of error information or the expressive power of throwing an 
>> error with the downside of a lot of boilerpate and poor integration with 
>> generics.
>> Here’s an example pseudo-swift that illustrates this:
>> 
>> enum Failable {
>>  
>>  case success(Wrapped)
>> 
>>  case failure(Error)
>> 
>> }
>> 
>> func foo() throws -> Int {
>>  guard myCondition else {
>>  throw EmbarressingError.oops
>>  }
>>  return 42
>> }
>> 
>> let failable = catch foo() // Failable
>> 
>> func bar() throws -> Int {
>>  throw failable
>> 
>> 
>> 
>>> On May 1, 2017, at 11:17 AM, Rod Brown >> > wrote:
>>> 
>>> The problem I see with your argument is that the core reason why the 
>>> optional cast failed is actually there: It was an optional value, and you 
>>> forced it to unwrap without checking. This is a correct description of the 
>>> error.
>>> 
>>> If we plumbed our code with a tonne of errors saying “why this is optional, 
>>> and why it is null” then we are practically making every optional an error 
>>> in the case of nil, which is completely illogical considering that nil 
>>> could be a completely legitimate case (especially in the case of 
>>> not-implicitly-unwrapped optionals).
>>> 
>>> Optional is a wrapper for "value-or-null", not "value-or-reason-not-value".
>>> 
>>> The type you are talking about is a result/sum type as 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Rod Brown via swift-evolution]

> On 1 May 2017, at 8:16 pm, Gor Gyolchanyan  wrote:
> 
> Yeah, you’re absolutely right. the “value-or-nil” and 
> “value-or-reason-why-not-value” are two different things and the former is 
> used too liberally in place of the latter because of lack of support.
> In that case, the Result type should not replace the error handling, but 
> augment it. The error handling mechanism is extremely well though-out and 
> convenient for its purpose, but it makes it difficult to capture and store a 
> union of (value; flying error).

I agree that the key problem with the current architecture that you're alluding 
to is it can't be easily stored and transferred. Swift errors are great for 
live action but holding and passing after the throwing event is problematic, 
and this is an elegant solution. The storage issue is when holding it as a 
property, and the transferring issue is when passing it to a closure as a 
results of an asynchronous operation etc. These are both definitely cases where 
storage of the type-or-error makes perfect sense.

I think the key problem getting this accepted by the Swift Team will be that it 
doesn't currently have any specific use in the standard library. As a low level 
set of types, errors are generated by the lower levels but rarely stored, so 
the Standard library doesn't need the storage. Generally the only place we have 
to do that is in end user code. And currently the standard library doesn't have 
to support asynchronous operations natively, so there's nothing inside the kit 
that would require it to do completion handlers with errors.

This would therefore be an element in the standard library purely so we don't 
have 50,000 different libraries with 50,000 different result types. I'd love to 
see this standardised so frameworks were more compatible. I'm just not sure 
whether the Core Team would see it as pressing to try and officiate a certain 
type that they themselves don't use.


> A built-in Failable enum with syntactic support to losslessly catch it from a 
> throwing expression and unpack it into a throwing scope would be a very 
> useful feature.
> Optionals are extremely convenient, but in cases where the Optional is used 
> as “value-or-error” rather then “value-or-nil” it falls a bit short and the 
> programmer has to choose between extreme convenience of Optionals with the 
> downside of lack of error information or the expressive power of throwing an 
> error with the downside of a lot of boilerpate and poor integration with 
> generics.
> Here’s an example pseudo-swift that illustrates this:
> 
> enum Failable {
>   
>   case success(Wrapped)
> 
>   case failure(Error)
> 
> }
> 
> func foo() throws -> Int {
>   guard myCondition else {
>   throw EmbarressingError.oops
>   }
>   return 42
> }
> 
> let failable = catch foo() // Failable
> 
> func bar() throws -> Int {
>   throw failable
> 
> 
> 
>> On May 1, 2017, at 11:17 AM, Rod Brown  wrote:
>> 
>> The problem I see with your argument is that the core reason why the 
>> optional cast failed is actually there: It was an optional value, and you 
>> forced it to unwrap without checking. This is a correct description of the 
>> error.
>> 
>> If we plumbed our code with a tonne of errors saying “why this is optional, 
>> and why it is null” then we are practically making every optional an error 
>> in the case of nil, which is completely illogical considering that nil could 
>> be a completely legitimate case (especially in the case of 
>> not-implicitly-unwrapped optionals).
>> 
>> Optional is a wrapper for "value-or-null", not "value-or-reason-not-value".
>> 
>> The type you are talking about is a result/sum type as has been mentioned, 
>> which is fine, and is completely valid (I use them a lot too) but they are 
>> definitely not the same thing as an optional, and I think you’re conflating 
>> the two ideas.
>> 
>> - Rod
>> 
>> 
>>> On 1 May 2017, at 5:58 pm, Gor Gyolchanyan via swift-evolution 
>>>  wrote:
>>> 
>>> I have read those documents before, but It’s worth re-reading them to see 
>>> if I missed something, but I’l still explain my motivation and seek 
>>> arguments against the postulated problem (rather then a specific solution).
>>> 
>>> (a) There are different types of error.
>>> 
>>> Yes, there are different types of error in Swift, which require different 
>>> reactions from the programmer.
>>> If I’m not missing something, the three main types of error in Swift are:
>>>  - Simple encapsulatable errors that are expected to be treated as normal 
>>> values until the time comes for someone to take care of them by unpacking 
>>> the content.
>>>  - Automatic propagatable errors that require the programmer to either 
>>> handle the error immediately or propagate it by delegating to its own 
>>> caller.
>>> - Fatal errors, which represent logic errors and broken invariants and 
>>> 

Re: [swift-evolution] [Pitch] Move All Discussions To Github Issues

[Mohamed Ebrahim Afifi via swift-evolution]

Thanks for your reply! I think that is very good news that the burden of
the mailing list is so obvious for everyone!

I think Github issues would be better though, the community is used to it
and it makes more sense as it needs almost no configurations, no operation
costs or maintenance. If the community decided to move to it we can move to
it immediately, we don't need to wait. It is a natural next step since the
proposals are maintained there and Swift itself is maintained there.


Do you have a link to that discussion?




Best Regards,
Mohamed Afifi

On Mon, May 1, 2017 at 1:33 PM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> Hi there,
>
> you’re a bit too late. A forum will come at some point (Discourse).
>
> Best regards,
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 1. Mai 2017 um 13:30:55, Mohamed Ebrahim Afifi via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Hi,
>
> This is actually not a proposal to improve Swift, it is actually a
> proposal to improve the way we use it to improve Swift. :)
>
> It is extremely hard to monitor discussions going over e-mails.
>
>1. I always get lost between e-mails especially if there are so many
>replies
>2. It is extremely hard to reach the original idea/first e-mail.
>3. New people (like me) usually get lost between e-mails and only
>focus on their own idea and don't care about other's ideas because for
>example, I don't know how to reply to an idea if I'm not subscribed to the
>mailing list. In other words, It’s not a system that encourages follow-up
>actions.
>4. You can not browse subjects and all replies in one place.
>5. You cannot follow a specific topic and ignore others.
>
> That was the problem!
>
> My suggestion is to move all discussions from this mailing list to GitHub
> issues. For the following reasons.
>
>1. Easier to browse all topics.
>2. You can see open topics and closed topics. So, if a topic is done
>we can close it.
>3. You can subscribe to a topic and follow all replies and reply.
>4. Markdown support. Currently, I see people create a markdown page on
>Github and send a link to it on the mailing list. But having the markdown
>inline in the topic is a great benefit. Also, replies can be in markdown as
>well.
>5. It's closer to Proposals (Since we already using Github for
>tracking proposals why don't we use it also to track pitching ideas).
>People like to have everything gathered together in one place and don't
>need to remember the Github repo and mailing list.
>6. Github has https://developer.github.com/v3/issues/
>
>
> I think using Github issues instead of the mailing lists will increase
> the engagement of the Swift community with proposals.
>
>
> Best Regards,
> Mohamed Afifi
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Move All Discussions To Github Issues

[Adrian Zubarev via swift-evolution]

Hi there,

you’re a bit too late. A forum will come at some point (Discourse).

Best regards,



-- 
Adrian Zubarev
Sent with Airmail

Am 1. Mai 2017 um 13:30:55, Mohamed Ebrahim Afifi via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hi,

This is actually not a proposal to improve Swift, it is actually a proposal to 
improve the way we use it to improve Swift. :)

It is extremely hard to monitor discussions going over e-mails.
I always get lost between e-mails especially if there are so many replies
It is extremely hard to reach the original idea/first e-mail.
New people (like me) usually get lost between e-mails and only focus on their 
own idea and don't care about other's ideas because for example, I don't know 
how to reply to an idea if I'm not subscribed to the mailing list. In other 
words, It’s not a system that encourages follow-up actions.
You can not browse subjects and all replies in one place.
You cannot follow a specific topic and ignore others.
That was the problem! 

My suggestion is to move all discussions from this mailing list to GitHub 
issues. For the following reasons.
Easier to browse all topics.
You can see open topics and closed topics. So, if a topic is done we can close 
it.
You can subscribe to a topic and follow all replies and reply. 
Markdown support. Currently, I see people create a markdown page on Github and 
send a link to it on the mailing list. But having the markdown inline in the 
topic is a great benefit. Also, replies can be in markdown as well.
It's closer to Proposals (Since we already using Github for tracking proposals 
why don't we use it also to track pitching ideas). People like to have 
everything gathered together in one place and don't need to remember the Github 
repo and mailing list.
Github has https://developer.github.com/v3/issues/ 

I think using Github issues instead of the mailing lists will increase the 
engagement of the Swift community with proposals.


Best Regards,
Mohamed Afifi
___
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] [Pitch] Move All Discussions To Github Issues

[Mohamed Ebrahim Afifi via swift-evolution]

Hi,

This is actually not a proposal to improve Swift, it is actually a proposal
to improve the way we use it to improve Swift. :)

It is extremely hard to monitor discussions going over e-mails.

   1. I always get lost between e-mails especially if there are so many
   replies
   2. It is extremely hard to reach the original idea/first e-mail.
   3. New people (like me) usually get lost between e-mails and only focus
   on their own idea and don't care about other's ideas because for example, I
   don't know how to reply to an idea if I'm not subscribed to the mailing
   list. In other words, It’s not a system that encourages follow-up actions.
   4. You can not browse subjects and all replies in one place.
   5. You cannot follow a specific topic and ignore others.

That was the problem!

My suggestion is to move all discussions from this mailing list to GitHub
issues. For the following reasons.

   1. Easier to browse all topics.
   2. You can see open topics and closed topics. So, if a topic is done we
   can close it.
   3. You can subscribe to a topic and follow all replies and reply.
   4. Markdown support. Currently, I see people create a markdown page on
   Github and send a link to it on the mailing list. But having the markdown
   inline in the topic is a great benefit. Also, replies can be in markdown as
   well.
   5. It's closer to Proposals (Since we already using Github for tracking
   proposals why don't we use it also to track pitching ideas). People like to
   have everything gathered together in one place and don't need to remember
   the Github repo and mailing list.
   6. Github has https://developer.github.com/v3/issues/


I think using Github issues instead of the mailing lists will increase
the engagement of the Swift community with proposals.


Best Regards,
Mohamed Afifi
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Gor Gyolchanyan via swift-evolution]

The real beauty of this added mechanism is when you consider generics. It would 
be easy to write a generic function that operates on both throwing and 
non-throwing parameters, while preserving their throwing-ness. Think `rethrows` 
except not limited to immediate nonescaping calls.
This part needs some serious thought, but having throwing functions play nice 
with generics would be spectacular.

> On May 1, 2017, at 1:53 PM, Gor Gyolchanyan  wrote:
> 
> I guess I failed to communicate my thoughts properly. My bad.
> You’re right, this is a completely orthogonal issue and you're right: this 
> does take nothing more then a new enum type and syntax sugar on top of it.
> 
> My first guess is to allow this:
> 
> func foo() throws -> Int {
>   guard myCondition else {
>   throw EmbarrassingError.oops
>   }
>   return 42
> }
> 
> let failable: Failable = catch foo()
> 
> func bar() throws -> String {
>   let int = try failable
>   return “\(int)"
> }
> 
> This doesn’t intersect with any existing syntax, so it should be additive.
> 
>> On May 1, 2017, at 1:15 PM, Xiaodi Wu  wrote:
>> 
>>> On Mon, May 1, 2017 at 2:58 AM, Gor Gyolchanyan  
>>> wrote:
>>> I have read those documents before, but It’s worth re-reading them to see 
>>> if I missed something, but I’l still explain my motivation and seek 
>>> arguments against the postulated problem (rather then a specific solution).
>>> 
>>> (a) There are different types of error.
>>> 
>>> Yes, there are different types of error in Swift, which require different 
>>> reactions from the programmer.
>>> If I’m not missing something, the three main types of error in Swift are:
>>>  - Simple encapsulatable errors that are expected to be treated as normal 
>>> values until the time comes for someone to take care of them by unpacking 
>>> the content.
>>>  - Automatic propagatable errors that require the programmer to either 
>>> handle the error immediately or propagate it by delegating to its own 
>>> caller.
>>> - Fatal errors, which represent logic errors and broken invariants and 
>>> preconditions, which are purely a programmer error and should not be dealt 
>>> with dynamically, hence the terminated process with a message.
>>> 
>>> (b) The programmer is expected to react differently to different types of 
>>> error.
>>> 
>>> Yes, and the three main ways a programmer is expected to react to the an 
>>> error are:
>>>  - If it’s an optional, they’re encouraged to store and pass it around 
>>> freely until someone down the line decides to unpack it and deal with the 
>>> possibility that it isn’t there.
>>>  - If it’s an error, they’re encouraged to either handle it on the spot or 
>>> declare themselves throwing and delegate the responsibility to the caller.
>>>  - Look at the standard output and figure out why the fatal error occurred, 
>>> perhaps with the help of the debugger.
>>> 
>>> (c) The language is a tool to help the programmer react.
>>> 
>>> Yes, that comes in the form of three language constructs:
>>>  - Optionals, which allow storing a union of a value and its absence (for 
>>> an undefined and hopefully obvious reason).
>>>  - Throwing functions, which allow making sure that the error will be 
>>> handled as soon as possible.
>>>  - Fatal errors, which allow the programmer to mark points in code which 
>>> should never be reached in a correct system in order to keep the logic from 
>>> going AWOL in case the programmer screwed up somewhere.
>>> 
>>> (d) Optionals and errors are not unified, and unification is a non-goal, 
>>> because they are designed to help the programmer react differently to 
>>> different types of error.
>>> 
>>> Yes, and those different types of error with different reactions are all 
>>> valid and shouldn’t be unified.
>>> My point is that the language should make it easy for a programmer to 
>>> transition from one type of error to another, because the same error has 
>>> different severity in different contexts.
>>> For instance, a “file not found” error when trying to open a file handler 
>>> is not critical at all in the context of the file opening function, because 
>>> it’s a perfectly expected outcome of the operation.
>>> However, for a module that handles loading critical data from disk (like 
>>> encryption keys needed to decrypt the manipulated content) it is a critical 
>>> error that cannot be dealt with.
>>> In this case it deserves to be a fatal error, because the programmer didn’t 
>>> bother to implement a logic for creating the missing file or properly 
>>> notifying the user of the lacking permissions to do so.
>>> Conversely, some errors start as being urgent (like a JSON parser that 
>>> throws an error when it encounters invalid syntax), but become less urgent 
>>> for the client (a JSON editor that simply displays the error message).
>> 
>> Again, that's not my understanding for the rationale behind having both 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Gor Gyolchanyan via swift-evolution]

I guess I failed to communicate my thoughts properly. My bad.
You’re right, this is a completely orthogonal issue and you're right: this does 
take nothing more then a new enum type and syntax sugar on top of it.

My first guess is to allow this:

func foo() throws -> Int {
guard myCondition else {
throw EmbarrassingError.oops
}
return 42
}

let failable: Failable = catch foo()

func bar() throws -> String {
let int = try failable
return “\(int)"
}

This doesn’t intersect with any existing syntax, so it should be additive.

> On May 1, 2017, at 1:15 PM, Xiaodi Wu  wrote:
> 
> On Mon, May 1, 2017 at 2:58 AM, Gor Gyolchanyan  > wrote:
> I have read those documents before, but It’s worth re-reading them to see if 
> I missed something, but I’l still explain my motivation and seek arguments 
> against the postulated problem (rather then a specific solution).
> 
> (a) There are different types of error.
> 
> Yes, there are different types of error in Swift, which require different 
> reactions from the programmer.
> If I’m not missing something, the three main types of error in Swift are:
>  - Simple encapsulatable errors that are expected to be treated as normal 
> values until the time comes for someone to take care of them by unpacking the 
> content.
>  - Automatic propagatable errors that require the programmer to either handle 
> the error immediately or propagate it by delegating to its own caller.
> - Fatal errors, which represent logic errors and broken invariants and 
> preconditions, which are purely a programmer error and should not be dealt 
> with dynamically, hence the terminated process with a message.
> 
> (b) The programmer is expected to react differently to different types of 
> error.
> 
> Yes, and the three main ways a programmer is expected to react to the an 
> error are:
>  - If it’s an optional, they’re encouraged to store and pass it around freely 
> until someone down the line decides to unpack it and deal with the 
> possibility that it isn’t there.
>  - If it’s an error, they’re encouraged to either handle it on the spot or 
> declare themselves throwing and delegate the responsibility to the caller.
>  - Look at the standard output and figure out why the fatal error occurred, 
> perhaps with the help of the debugger.
> 
> (c) The language is a tool to help the programmer react.
> 
> Yes, that comes in the form of three language constructs:
>  - Optionals, which allow storing a union of a value and its absence (for an 
> undefined and hopefully obvious reason).
>  - Throwing functions, which allow making sure that the error will be handled 
> as soon as possible.
>  - Fatal errors, which allow the programmer to mark points in code which 
> should never be reached in a correct system in order to keep the logic from 
> going AWOL in case the programmer screwed up somewhere.
> 
> (d) Optionals and errors are not unified, and unification is a non-goal, 
> because they are designed to help the programmer react differently to 
> different types of error.
> 
> Yes, and those different types of error with different reactions are all 
> valid and shouldn’t be unified.
> My point is that the language should make it easy for a programmer to 
> transition from one type of error to another, because the same error has 
> different severity in different contexts.
> For instance, a “file not found” error when trying to open a file handler is 
> not critical at all in the context of the file opening function, because it’s 
> a perfectly expected outcome of the operation.
> However, for a module that handles loading critical data from disk (like 
> encryption keys needed to decrypt the manipulated content) it is a critical 
> error that cannot be dealt with.
> In this case it deserves to be a fatal error, because the programmer didn’t 
> bother to implement a logic for creating the missing file or properly 
> notifying the user of the lacking permissions to do so.
> Conversely, some errors start as being urgent (like a JSON parser that throws 
> an error when it encounters invalid syntax), but become less urgent for the 
> client (a JSON editor that simply displays the error message).
> 
> Again, that's not my understanding for the rationale behind having both 
> Optional return values and errors. It's not that one is more "urgent" or 
> "important" than the other. An Optional is used when something can only fail 
> in one obvious way; an error is thrown when it can fail in multiple, but 
> recoverable, ways. You can care a lot about a nil value and not at all about 
> an error, or vice versa.
> 
> 
> As for my use case:
> 
> I have a JSON parser that may throw, and I have a a JSON Editor class that 
> allows editing JSON files as well as displaying the parsing errors.
> I have a malformed JSON file that I open in the editor. The JSON parser 
> throws an error, which 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Gor Gyolchanyan via swift-evolution]

Yeah, you’re absolutely right. the “value-or-nil” and 
“value-or-reason-why-not-value” are two different things and the former is used 
too liberally in place of the latter because of lack of support.
In that case, the Result type should not replace the error handling, but 
augment it. The error handling mechanism is extremely well though-out and 
convenient for its purpose, but it makes it difficult to capture and store a 
union of (value; flying error).
A built-in Failable enum with syntactic support to losslessly catch it from a 
throwing expression and unpack it into a throwing scope would be a very useful 
feature.
Optionals are extremely convenient, but in cases where the Optional is used as 
“value-or-error” rather then “value-or-nil” it falls a bit short and the 
programmer has to choose between extreme convenience of Optionals with the 
downside of lack of error information or the expressive power of throwing an 
error with the downside of a lot of boilerpate and poor integration with 
generics.
Here’s an example pseudo-swift that illustrates this:

enum Failable {

case success(Wrapped)

case failure(Error)

}

func foo() throws -> Int {
guard myCondition else {
throw EmbarressingError.oops
}
return 42
}

let failable = catch foo() // Failable

func bar() throws -> Int {
throw failable
}


> On May 1, 2017, at 11:17 AM, Rod Brown  wrote:
> 
> The problem I see with your argument is that the core reason why the optional 
> cast failed is actually there: It was an optional value, and you forced it to 
> unwrap without checking. This is a correct description of the error.
> 
> If we plumbed our code with a tonne of errors saying “why this is optional, 
> and why it is null” then we are practically making every optional an error in 
> the case of nil, which is completely illogical considering that nil could be 
> a completely legitimate case (especially in the case of 
> not-implicitly-unwrapped optionals).
> 
> Optional is a wrapper for "value-or-null", not "value-or-reason-not-value".
> 
> The type you are talking about is a result/sum type as has been mentioned, 
> which is fine, and is completely valid (I use them a lot too) but they are 
> definitely not the same thing as an optional, and I think you’re conflating 
> the two ideas.
> 
> - Rod
> 
> 
>> On 1 May 2017, at 5:58 pm, Gor Gyolchanyan via swift-evolution 
>> > wrote:
>> 
>> I have read those documents before, but It’s worth re-reading them to see if 
>> I missed something, but I’l still explain my motivation and seek arguments 
>> against the postulated problem (rather then a specific solution).
>> 
>> (a) There are different types of error.
>> 
>> Yes, there are different types of error in Swift, which require different 
>> reactions from the programmer.
>> If I’m not missing something, the three main types of error in Swift are:
>>  - Simple encapsulatable errors that are expected to be treated as normal 
>> values until the time comes for someone to take care of them by unpacking 
>> the content.
>>  - Automatic propagatable errors that require the programmer to either 
>> handle the error immediately or propagate it by delegating to its own caller.
>> - Fatal errors, which represent logic errors and broken invariants and 
>> preconditions, which are purely a programmer error and should not be dealt 
>> with dynamically, hence the terminated process with a message.
>> 
>> (b) The programmer is expected to react differently to different types of 
>> error.
>> 
>> Yes, and the three main ways a programmer is expected to react to the an 
>> error are:
>>  - If it’s an optional, they’re encouraged to store and pass it around 
>> freely until someone down the line decides to unpack it and deal with the 
>> possibility that it isn’t there.
>>  - If it’s an error, they’re encouraged to either handle it on the spot or 
>> declare themselves throwing and delegate the responsibility to the caller.
>>  - Look at the standard output and figure out why the fatal error occurred, 
>> perhaps with the help of the debugger.
>> 
>> (c) The language is a tool to help the programmer react.
>> 
>> Yes, that comes in the form of three language constructs:
>>  - Optionals, which allow storing a union of a value and its absence (for an 
>> undefined and hopefully obvious reason).
>>  - Throwing functions, which allow making sure that the error will be 
>> handled as soon as possible.
>>  - Fatal errors, which allow the programmer to mark points in code which 
>> should never be reached in a correct system in order to keep the logic from 
>> going AWOL in case the programmer screwed up somewhere.
>> 
>> (d) Optionals and errors are not unified, and unification is a non-goal, 
>> because they are designed to help the programmer react differently to 
>> different types of error.
>> 
>> Yes, and those 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Xiaodi Wu via swift-evolution]

On Mon, May 1, 2017 at 2:58 AM, Gor Gyolchanyan  wrote:

> I have read those documents before, but It’s worth re-reading them to see
> if I missed something, but I’l still explain my motivation and seek
> arguments against the postulated problem (rather then a specific solution).
>
> (a) There are different types of error.
>
> Yes, there are different types of error in Swift, which require different
> reactions from the programmer.
> If I’m not missing something, the three main types of error in Swift are:
>  - Simple encapsulatable errors that are expected to be treated as normal
> values until the time comes for someone to take care of them by unpacking
> the content.
>  - Automatic propagatable errors that require the programmer to either
> handle the error immediately or propagate it by delegating to its own
> caller.
> - Fatal errors, which represent logic errors and broken invariants and
> preconditions, which are purely a programmer error and should not be dealt
> with dynamically, hence the terminated process with a message.
>
> (b) The programmer is expected to react differently to different types of
> error.
>
> Yes, and the three main ways a programmer is expected to react to the an
> error are:
>  - If it’s an optional, they’re encouraged to store and pass it around
> freely until someone down the line decides to unpack it and deal with the
> possibility that it isn’t there.
>  - If it’s an error, they’re encouraged to either handle it on the spot or
> declare themselves throwing and delegate the responsibility to the caller.
>  - Look at the standard output and figure out why the fatal error
> occurred, perhaps with the help of the debugger.
>
> (c) The language is a tool to help the programmer react.
>
> Yes, that comes in the form of three language constructs:
>  - Optionals, which allow storing a union of a value and its absence (for
> an undefined and hopefully obvious reason).
>  - Throwing functions, which allow making sure that the error will be
> handled as soon as possible.
>  - Fatal errors, which allow the programmer to mark points in code which
> should never be reached in a correct system in order to keep the logic from
> going AWOL in case the programmer screwed up somewhere.
>
> (d) Optionals and errors are not unified, and unification is a non-goal,
> because they are designed to help the programmer react differently to
> different types of error.
>
> Yes, and those different types of error with different reactions are all
> valid and shouldn’t be unified.
> My point is that the language should make it easy for a programmer to
> transition from one type of error to another, because the same error has
> different severity in different contexts.
> For instance, a “file not found” error when trying to open a file handler
> is not critical at all in the context of the file opening function, because
> it’s a perfectly expected outcome of the operation.
> However, for a module that handles loading critical data from disk (like
> encryption keys needed to decrypt the manipulated content) it is a critical
> error that cannot be dealt with.
> In this case it deserves to be a fatal error, because the programmer
> didn’t bother to implement a logic for creating the missing file or
> properly notifying the user of the lacking permissions to do so.
> Conversely, some errors start as being urgent (like a JSON parser that
> throws an error when it encounters invalid syntax), but become less urgent
> for the client (a JSON editor that simply displays the error message).
>

Again, that's not my understanding for the rationale behind having both
Optional return values and errors. It's not that one is more "urgent" or
"important" than the other. An Optional is used when something can only
fail in one obvious way; an error is thrown when it can fail in multiple,
but recoverable, ways. You can care a lot about a nil value and not at all
about an error, or vice versa.


As for my use case:
>
> I have a JSON parser that may throw, and I have a a JSON Editor class that
> allows editing JSON files as well as displaying the parsing errors.
> I have a malformed JSON file that I open in the editor. The JSON parser
> throws an error, which should be caught and stored somewhere for the editor
> to display.
> I have file reader that reads a file in some encoding and returns an
> optional string with the file contents (nil means file couldn’t be read or
> the encoding is wrong).
>
> For the JSON parser, a malformed JSON file is an obvious error, but for
> the editor, it’s a perfectly valid and expected condition, which doesn’t
> deserve to be an error.
> Therefore, the thrown error of the JSON parse has to be caught and
> encapsulated indiscriminately to demote it from an error to a return value.
> Conversely, the returned nil form the file reader is perfectly valid and
> expected condition, but for the editor, it’s an error.
> Therefore, the returned nil should be checked and converted 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Rod Brown via swift-evolution]

The problem I see with your argument is that the core reason why the optional 
cast failed is actually there: It was an optional value, and you forced it to 
unwrap without checking. This is a correct description of the error.

If we plumbed our code with a tonne of errors saying “why this is optional, and 
why it is null” then we are practically making every optional an error in the 
case of nil, which is completely illogical considering that nil could be a 
completely legitimate case (especially in the case of not-implicitly-unwrapped 
optionals).

Optional is a wrapper for "value-or-null", not "value-or-reason-not-value".

The type you are talking about is a result/sum type as has been mentioned, 
which is fine, and is completely valid (I use them a lot too) but they are 
definitely not the same thing as an optional, and I think you’re conflating the 
two ideas.

- Rod


> On 1 May 2017, at 5:58 pm, Gor Gyolchanyan via swift-evolution 
>  wrote:
> 
> I have read those documents before, but It’s worth re-reading them to see if 
> I missed something, but I’l still explain my motivation and seek arguments 
> against the postulated problem (rather then a specific solution).
> 
> (a) There are different types of error.
> 
> Yes, there are different types of error in Swift, which require different 
> reactions from the programmer.
> If I’m not missing something, the three main types of error in Swift are:
>  - Simple encapsulatable errors that are expected to be treated as normal 
> values until the time comes for someone to take care of them by unpacking the 
> content.
>  - Automatic propagatable errors that require the programmer to either handle 
> the error immediately or propagate it by delegating to its own caller.
> - Fatal errors, which represent logic errors and broken invariants and 
> preconditions, which are purely a programmer error and should not be dealt 
> with dynamically, hence the terminated process with a message.
> 
> (b) The programmer is expected to react differently to different types of 
> error.
> 
> Yes, and the three main ways a programmer is expected to react to the an 
> error are:
>  - If it’s an optional, they’re encouraged to store and pass it around freely 
> until someone down the line decides to unpack it and deal with the 
> possibility that it isn’t there.
>  - If it’s an error, they’re encouraged to either handle it on the spot or 
> declare themselves throwing and delegate the responsibility to the caller.
>  - Look at the standard output and figure out why the fatal error occurred, 
> perhaps with the help of the debugger.
> 
> (c) The language is a tool to help the programmer react.
> 
> Yes, that comes in the form of three language constructs:
>  - Optionals, which allow storing a union of a value and its absence (for an 
> undefined and hopefully obvious reason).
>  - Throwing functions, which allow making sure that the error will be handled 
> as soon as possible.
>  - Fatal errors, which allow the programmer to mark points in code which 
> should never be reached in a correct system in order to keep the logic from 
> going AWOL in case the programmer screwed up somewhere.
> 
> (d) Optionals and errors are not unified, and unification is a non-goal, 
> because they are designed to help the programmer react differently to 
> different types of error.
> 
> Yes, and those different types of error with different reactions are all 
> valid and shouldn’t be unified.
> My point is that the language should make it easy for a programmer to 
> transition from one type of error to another, because the same error has 
> different severity in different contexts.
> For instance, a “file not found” error when trying to open a file handler is 
> not critical at all in the context of the file opening function, because it’s 
> a perfectly expected outcome of the operation.
> However, for a module that handles loading critical data from disk (like 
> encryption keys needed to decrypt the manipulated content) it is a critical 
> error that cannot be dealt with.
> In this case it deserves to be a fatal error, because the programmer didn’t 
> bother to implement a logic for creating the missing file or properly 
> notifying the user of the lacking permissions to do so.
> Conversely, some errors start as being urgent (like a JSON parser that throws 
> an error when it encounters invalid syntax), but become less urgent for the 
> client (a JSON editor that simply displays the error message).
> 
> As for my use case:
> 
> I have a JSON parser that may throw, and I have a a JSON Editor class that 
> allows editing JSON files as well as displaying the parsing errors.
> I have a malformed JSON file that I open in the editor. The JSON parser 
> throws an error, which should be caught and stored somewhere for the editor 
> to display.
> I have file reader that reads a file in some encoding and returns an optional 
> string with the file contents (nil means file 

Re: [swift-evolution] [Pitch] Revamp Optional and Throws

[Gor Gyolchanyan via swift-evolution]

I have read those documents before, but It’s worth re-reading them to see if I 
missed something, but I’l still explain my motivation and seek arguments 
against the postulated problem (rather then a specific solution).

(a) There are different types of error.

Yes, there are different types of error in Swift, which require different 
reactions from the programmer.
If I’m not missing something, the three main types of error in Swift are:
 - Simple encapsulatable errors that are expected to be treated as normal 
values until the time comes for someone to take care of them by unpacking the 
content.
 - Automatic propagatable errors that require the programmer to either handle 
the error immediately or propagate it by delegating to its own caller.
- Fatal errors, which represent logic errors and broken invariants and 
preconditions, which are purely a programmer error and should not be dealt with 
dynamically, hence the terminated process with a message.

(b) The programmer is expected to react differently to different types of error.

Yes, and the three main ways a programmer is expected to react to the an error 
are:
 - If it’s an optional, they’re encouraged to store and pass it around freely 
until someone down the line decides to unpack it and deal with the possibility 
that it isn’t there.
 - If it’s an error, they’re encouraged to either handle it on the spot or 
declare themselves throwing and delegate the responsibility to the caller.
 - Look at the standard output and figure out why the fatal error occurred, 
perhaps with the help of the debugger.

(c) The language is a tool to help the programmer react.

Yes, that comes in the form of three language constructs:
 - Optionals, which allow storing a union of a value and its absence (for an 
undefined and hopefully obvious reason).
 - Throwing functions, which allow making sure that the error will be handled 
as soon as possible.
 - Fatal errors, which allow the programmer to mark points in code which should 
never be reached in a correct system in order to keep the logic from going AWOL 
in case the programmer screwed up somewhere.

(d) Optionals and errors are not unified, and unification is a non-goal, 
because they are designed to help the programmer react differently to different 
types of error.

Yes, and those different types of error with different reactions are all valid 
and shouldn’t be unified.
My point is that the language should make it easy for a programmer to 
transition from one type of error to another, because the same error has 
different severity in different contexts.
For instance, a “file not found” error when trying to open a file handler is 
not critical at all in the context of the file opening function, because it’s a 
perfectly expected outcome of the operation.
However, for a module that handles loading critical data from disk (like 
encryption keys needed to decrypt the manipulated content) it is a critical 
error that cannot be dealt with.
In this case it deserves to be a fatal error, because the programmer didn’t 
bother to implement a logic for creating the missing file or properly notifying 
the user of the lacking permissions to do so.
Conversely, some errors start as being urgent (like a JSON parser that throws 
an error when it encounters invalid syntax), but become less urgent for the 
client (a JSON editor that simply displays the error message).

As for my use case:

I have a JSON parser that may throw, and I have a a JSON Editor class that 
allows editing JSON files as well as displaying the parsing errors.
I have a malformed JSON file that I open in the editor. The JSON parser throws 
an error, which should be caught and stored somewhere for the editor to display.
I have file reader that reads a file in some encoding and returns an optional 
string with the file contents (nil means file couldn’t be read or the encoding 
is wrong).

For the JSON parser, a malformed JSON file is an obvious error, but for the 
editor, it’s a perfectly valid and expected condition, which doesn’t deserve to 
be an error.
Therefore, the thrown error of the JSON parse has to be caught and encapsulated 
indiscriminately to demote it from an error to a return value.
Conversely, the returned nil form the file reader is perfectly valid and 
expected condition, but for the editor, it’s an error.
Therefore, the returned nil should be checked and converted to an error that 
will be thrown to promote it to a full-fledged error.

I would want to have a way to easily promote/demote different types of errors 
to accommodate the changing perception of their urgency.
For instance, by being able to throw an optional, thus introducing a new way of 
unpacking it (by promoting it to an error). Currently, it is by manually 
unpacking the optional, deciding what error to throw and throwing it manually.
Or, being able to catch an error into an optional, thus introducing a new way 
of handling it (by demoting it to an optional). There is a way to do that