Re: [swift-evolution] Support for a KeyCodingStrategy option in JSONEncoder and JSONDecoder

[Eagle Offshore via swift-evolution]

> On Oct 23, 2017, at 3:19 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> having Codable does not contradict having introspection / reflection. 

But we don't have general introspection/reflection/dynamic invocation.  Which 
would have been a more worthwhile thing to spend time on as it enables many 
more features.

> general (or shall we say custom) approaches that use introspection / 
> reflection tend to work much slower (from Objective-C experience). i have no 
> data if Codable is performant in these regards but at least it has a 
> potential to be more optimal than a general solution based on introspection / 
> reflection.

Performance is at the very bottom of my list of things I care about - 
especially with regard to JSON processing or other format translations where 
the program is IO bound.

My Objective C KVC based mapper to SQLite was incredibly performant with mapkit 
when I was mapping thousands of pins stored in a very large local database.  
Performance, as an argument against flexibility, is completely unpersuasive.

Stuff is much more than fast enough in the application domain. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[Thorsten Seitz via swift-evolution]

Well, I have no problems with `flatMap` but then I am used to Monads.
I would not rename that overload if there is any hope that we might get Monads 
sometime in the future but probably there is none (which is sad).

So I would suggest `mapDroppingNil` or maybe `mapRejectingNil`.

-Thorsten


> Am 24.10.2017 um 05:38 schrieb Howard Lovatt via swift-evolution 
> :
> 
> +1 good idea.
> 
> Re. the naming I would suggest `mapFilterNil` since it says what it does and 
> filter, nil, and map are all understood already in Swift. (I have sympathy 
> for people wanting `mapFilteringNil`, but Swift chose `filter`.)
> 
> The problems I see with `filterMap` are that:
> 
>   1. It sounds like it is a merged `filter` and `map` and therefore you would 
> expect it to have two arguments, one to filter and one to map, i.e. 
> `filterMap(filter: (T) -> Bool, map: (T) -> R) -> [R]`.
>   2. It sounds like it will filter the incoming values (for `nil`, but see 1 
> above) and then map, i.e. `filterMap(map: (T?) -> R) -> [R]`, note `T?` 
> *not* `R?`.
> 
>   -- Howard.
> 
>> On 24 October 2017 at 11:56, BJ Homer via swift-evolution 
>>  wrote:
>> I agree with Xiaodi; I like ‘filterMap’ more than ‘filteredMap’. But both 
>> are superior to ‘flatMap’ in this context.
>> 
>> -BJ
>> 
>>> On Oct 23, 2017, at 5:22 PM, Max Moiseev  wrote:
>>> 
>>> It occurred to me that filteringMap(_:) should be even more descriptive, 
>>> still conform to the guidelines, although similarly unprecedented and 
>>> un-googlable.
>>> 
>>> Max
>>> 
 On Oct 23, 2017, at 3:52 PM, Xiaodi Wu  wrote:
 
 +1 in general. As to the name: since 'map' is used as a term of art, 
 'filterMap' seems superior to 'filteredMap', which half follows naming 
 guidelines and half is a term of art; neither is immediately 
 comprehensible but 'filterMap' can be googled and has precedents in other 
 languages.
 On Mon, Oct 23, 2017 at 17:24 BJ Homer via swift-evolution 
  wrote:
> I strongly agree! In fact, I just started writing up a similar proposal 
> the other day, but hadn’t had time to finish it yet.
> 
> The current name for this particular filtering variant is not 
> particularly descriptive. It’s certainly not obvious to newcomers that 
> ‘flatMap’ will filter out results. And it’s not true to the existing 
> usage of ‘flatMap' from other languages; you have to really squint at it 
> to see how any “flattening” is happening at all.
> 
> So yes, a big +1 from me. Thanks!
> 
> -BJ Homer
> 
>> On Oct 23, 2017, at 4:15 PM, Max Moiseev via swift-evolution 
>>  wrote:
>> 
>> Hi swift-evolution!
>> 
>> I would like to propose the following change to the standard library:
>> 
>> deprecate `Sequence.flatMap(_: (Element) -> U?) -> [U]` and make this 
>> functionality available under a new name `Sequence.filteredMap(_:)`.
>> 
>> The draft is available at 
>> https://gist.github.com/moiseev/2f36376c8ef4c2b1273cff0bfd9c3b95 and is 
>> included below for your convenience.
>> 
>> Max
>> 
>> Introduce Sequence.filteredMap(_:)
>> Proposal: SE-
>> Authors: Max Moiseev
>> Review Manager: TBD
>> Status: Awaiting implementation
>> Introduction
>> 
>> We propose to deprecate the controversial version of a Sequence.flatMap 
>> method and provide the same functionality under a different, and 
>> potentially more descriptive, name.
>> 
>> Motivation
>> 
>> The Swift standard library currently defines 3 distinct overloads for 
>> flatMap:
>> 
>> Sequence.flatMap(_: (Element) -> S) -> [S.Element]
>> where S : Sequence
>> Optional.flatMap(_: (Wrapped) -> U?) -> U?
>> Sequence.flatMap(_: (Element) -> U?) -> [U]
>> The last one, despite being useful in certain situations, can be (and 
>> often is) misused. Consider the following snippet:
>> 
>> struct Person {
>>   var age: Int
>>   var name: String
>> }
>> 
>> func getAges(people: [Person]) -> [Int] {
>>   return people.flatMap { $0.age }
>> }
>> What happens inside getNames is: thanks to the implicit promotion to 
>> Optional, the result of the closure gets wrapped into a .some, then 
>> immediately unwrapped by the implementation of flatMap, and appended to 
>> the result array. All this unnecessary wrapping and unwrapping can be 
>> easily avoided by just using map instead.
>> 
>> func getAges(people: [Person]) -> [Int] {
>>   return people.map { $0.age }
>> }
>> It gets even worse when we consider future code modifications, like the 
>> one where Swift 4 introduced a Stringconformance to the Collection 
>> protocol. The following code used to compile (due to the flatMap 

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[Xiaodi Wu via swift-evolution]

Well, in Swift as in other languages, to filter means to keep the stuff
that matches the predicate. So it's not "filter nil" but "filter some." But
actually, it's not a filter; it's a flat map operation, since the optional
is being unwrapped.

Also, based on the precedent of "flat map," I think it really should be
"filter map" and not "map filter," which would suggest incorrectly that the
predicate would be for filtering.


On Mon, Oct 23, 2017 at 22:38 Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 good idea.
>
> Re. the naming I would suggest `mapFilterNil` since it says what it does
> and filter, nil, and map are all understood already in Swift. (I have
> sympathy for people wanting `mapFilteringNil`, but Swift chose `filter`.)
>
> The problems I see with `filterMap` are that:
>
>   1. It sounds like it is a merged `filter` and `map` and therefore you
> would expect it to have two arguments, one to filter and one to map, i.e.
> `filterMap(filter: (T) -> Bool, map: (T) -> R) -> [R]`.
>   2. It sounds like it will filter the incoming values (for `nil`, but see
> 1 above) and then map, i.e. `filterMap(map: (T?) -> R) -> [R]`, note
> `T?` *not* `R?`.
>
>   -- Howard.
>
> On 24 October 2017 at 11:56, BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I agree with Xiaodi; I like ‘filterMap’ more than ‘filteredMap’. But both
>> are superior to ‘flatMap’ in this context.
>>
>> -BJ
>>
>> On Oct 23, 2017, at 5:22 PM, Max Moiseev  wrote:
>>
>> It occurred to me that filteringMap(_:) should be even more descriptive,
>> still conform to the guidelines, although similarly unprecedented and
>> un-googlable.
>>
>> Max
>>
>> On Oct 23, 2017, at 3:52 PM, Xiaodi Wu  wrote:
>>
>> +1 in general. As to the name: since 'map' is used as a term of art,
>> 'filterMap' seems superior to 'filteredMap', which half follows naming
>> guidelines and half is a term of art; neither is immediately comprehensible
>> but 'filterMap' can be googled and has precedents in other languages.
>> On Mon, Oct 23, 2017 at 17:24 BJ Homer via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I strongly agree! In fact, I just started writing up a similar proposal
>>> the other day, but hadn’t had time to finish it yet.
>>>
>>> The current name for this particular filtering variant is not
>>> particularly descriptive. It’s certainly not obvious to newcomers that
>>> ‘flatMap’ will filter out results. And it’s not true to the existing usage
>>> of ‘flatMap' from other languages; you have to really squint at it to see
>>> how any “flattening” is happening at all.
>>>
>>> So yes, a big +1 from me. Thanks!
>>>
>>> -BJ Homer
>>>
>>> On Oct 23, 2017, at 4:15 PM, Max Moiseev via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Hi swift-evolution!
>>>
>>> I would like to propose the following change to the standard library:
>>>
>>> deprecate `Sequence.flatMap(_: (Element) -> U?) -> [U]` and make this
>>> functionality available under a new name `Sequence.filteredMap(_:)`.
>>>
>>> The draft is available at
>>> https://gist.github.com/moiseev/2f36376c8ef4c2b1273cff0bfd9c3b95 and is
>>> included below for your convenience.
>>>
>>> Max
>>>
>>> Introduce Sequence.filteredMap(_:)
>>>
>>>- Proposal: SE-
>>>
>>>- Authors: Max Moiseev 
>>>- Review Manager: TBD
>>>- Status: Awaiting implementation
>>>
>>>
>>> 
>>> Introduction
>>>
>>> We propose to deprecate the controversial version of a Sequence.flatMap 
>>> method
>>> and provide the same functionality under a different, and potentially more
>>> descriptive, name.
>>>
>>> 
>>> Motivation
>>>
>>> The Swift standard library currently defines 3 distinct overloads for
>>> flatMap:
>>>
>>> Sequence.flatMap(_: (Element) -> S) -> [S.Element]
>>> where S : SequenceOptional.flatMap(_: (Wrapped) -> U?) -> 
>>> U?Sequence.flatMap(_: (Element) -> U?) -> [U]
>>>
>>> The last one, despite being useful in certain situations, can be (and
>>> often is) misused. Consider the following snippet:
>>>
>>> struct Person {
>>>   var age: Int
>>>   var name: String
>>> }
>>> func getAges(people: [Person]) -> [Int] {
>>>   return people.flatMap { $0.age }
>>> }
>>>
>>> What happens inside getNames is: thanks to the implicit promotion to
>>> Optional, the result of the closure gets wrapped into a .some, then
>>> immediately unwrapped by the implementation of flatMap, and appended to
>>> the result array. All this unnecessary wrapping and unwrapping can be
>>> easily avoided by just using map instead.
>>>
>>> func getAges(people: [Person]) -> [Int] {
>>>   return people.map { $0.age }
>>> }
>>>
>>> It gets even worse when we consider future code modifications, like the
>>> 

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[Howard Lovatt via swift-evolution]

+1 good idea.

Re. the naming I would suggest `mapFilterNil` since it says what it does
and filter, nil, and map are all understood already in Swift. (I have
sympathy for people wanting `mapFilteringNil`, but Swift chose `filter`.)

The problems I see with `filterMap` are that:

  1. It sounds like it is a merged `filter` and `map` and therefore you
would expect it to have two arguments, one to filter and one to map, i.e.
`filterMap(filter: (T) -> Bool, map: (T) -> R) -> [R]`.
  2. It sounds like it will filter the incoming values (for `nil`, but see
1 above) and then map, i.e. `filterMap(map: (T?) -> R) -> [R]`, note
`T?` *not* `R?`.

  -- Howard.

On 24 October 2017 at 11:56, BJ Homer via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree with Xiaodi; I like ‘filterMap’ more than ‘filteredMap’. But both
> are superior to ‘flatMap’ in this context.
>
> -BJ
>
> On Oct 23, 2017, at 5:22 PM, Max Moiseev  wrote:
>
> It occurred to me that filteringMap(_:) should be even more descriptive,
> still conform to the guidelines, although similarly unprecedented and
> un-googlable.
>
> Max
>
> On Oct 23, 2017, at 3:52 PM, Xiaodi Wu  wrote:
>
> +1 in general. As to the name: since 'map' is used as a term of art,
> 'filterMap' seems superior to 'filteredMap', which half follows naming
> guidelines and half is a term of art; neither is immediately comprehensible
> but 'filterMap' can be googled and has precedents in other languages.
> On Mon, Oct 23, 2017 at 17:24 BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I strongly agree! In fact, I just started writing up a similar proposal
>> the other day, but hadn’t had time to finish it yet.
>>
>> The current name for this particular filtering variant is not
>> particularly descriptive. It’s certainly not obvious to newcomers that
>> ‘flatMap’ will filter out results. And it’s not true to the existing usage
>> of ‘flatMap' from other languages; you have to really squint at it to see
>> how any “flattening” is happening at all.
>>
>> So yes, a big +1 from me. Thanks!
>>
>> -BJ Homer
>>
>> On Oct 23, 2017, at 4:15 PM, Max Moiseev via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi swift-evolution!
>>
>> I would like to propose the following change to the standard library:
>>
>> deprecate `Sequence.flatMap(_: (Element) -> U?) -> [U]` and make this
>> functionality available under a new name `Sequence.filteredMap(_:)`.
>>
>> The draft is available at https://gist.github.com/moiseev/
>> 2f36376c8ef4c2b1273cff0bfd9c3b95 and is included below for your
>> convenience.
>>
>> Max
>>
>> Introduce Sequence.filteredMap(_:)
>>
>>- Proposal: SE- 
>>- Authors: Max Moiseev 
>>- Review Manager: TBD
>>- Status: Awaiting implementation
>>
>>
>> 
>> Introduction
>>
>> We propose to deprecate the controversial version of a Sequence.flatMap 
>> method
>> and provide the same functionality under a different, and potentially more
>> descriptive, name.
>>
>> 
>> Motivation
>>
>> The Swift standard library currently defines 3 distinct overloads for
>> flatMap:
>>
>> Sequence.flatMap(_: (Element) -> S) -> [S.Element]
>> where S : SequenceOptional.flatMap(_: (Wrapped) -> U?) -> 
>> U?Sequence.flatMap(_: (Element) -> U?) -> [U]
>>
>> The last one, despite being useful in certain situations, can be (and
>> often is) misused. Consider the following snippet:
>>
>> struct Person {
>>   var age: Int
>>   var name: String
>> }
>> func getAges(people: [Person]) -> [Int] {
>>   return people.flatMap { $0.age }
>> }
>>
>> What happens inside getNames is: thanks to the implicit promotion to
>> Optional, the result of the closure gets wrapped into a .some, then
>> immediately unwrapped by the implementation of flatMap, and appended to
>> the result array. All this unnecessary wrapping and unwrapping can be
>> easily avoided by just using map instead.
>>
>> func getAges(people: [Person]) -> [Int] {
>>   return people.map { $0.age }
>> }
>>
>> It gets even worse when we consider future code modifications, like the
>> one where Swift 4 introduced a Stringconformance to the Collection protocol.
>> The following code used to compile (due to the flatMap overload in
>> question).
>>
>> func getNames(people: [Person]) -> [String] {
>>   return people.flatMap { $0.name }
>> }
>>
>> But it no longer does, because now there is a better overload that does
>> not involve implicit promotion. In this particular case, the compiler error
>> would be obvious, as it would point at the same line where flatMap is
>> used. Imagine however if it was just a let names = people.flatMap { $
>> 0.name } statement, and the names variable were used elsewhere. The
>> compiler error would be 

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[BJ Homer via swift-evolution]

I agree with Xiaodi; I like ‘filterMap’ more than ‘filteredMap’. But both are 
superior to ‘flatMap’ in this context.

-BJ

> On Oct 23, 2017, at 5:22 PM, Max Moiseev  wrote:
> 
> It occurred to me that filteringMap(_:) should be even more descriptive, 
> still conform to the guidelines, although similarly unprecedented and 
> un-googlable.
> 
> Max
> 
>> On Oct 23, 2017, at 3:52 PM, Xiaodi Wu  wrote:
>> 
>> +1 in general. As to the name: since 'map' is used as a term of art, 
>> 'filterMap' seems superior to 'filteredMap', which half follows naming 
>> guidelines and half is a term of art; neither is immediately comprehensible 
>> but 'filterMap' can be googled and has precedents in other languages.
>> On Mon, Oct 23, 2017 at 17:24 BJ Homer via swift-evolution 
>>  wrote:
>>> I strongly agree! In fact, I just started writing up a similar proposal the 
>>> other day, but hadn’t had time to finish it yet.
>>> 
>>> The current name for this particular filtering variant is not particularly 
>>> descriptive. It’s certainly not obvious to newcomers that ‘flatMap’ will 
>>> filter out results. And it’s not true to the existing usage of ‘flatMap' 
>>> from other languages; you have to really squint at it to see how any 
>>> “flattening” is happening at all.
>>> 
>>> So yes, a big +1 from me. Thanks!
>>> 
>>> -BJ Homer
>>> 
 On Oct 23, 2017, at 4:15 PM, Max Moiseev via swift-evolution 
  wrote:
 
 Hi swift-evolution!
 
 I would like to propose the following change to the standard library:
 
 deprecate `Sequence.flatMap(_: (Element) -> U?) -> [U]` and make this 
 functionality available under a new name `Sequence.filteredMap(_:)`.
 
 The draft is available at 
 https://gist.github.com/moiseev/2f36376c8ef4c2b1273cff0bfd9c3b95 and is 
 included below for your convenience.
 
 Max
 
 Introduce Sequence.filteredMap(_:)
 
 Proposal: SE-
 Authors: Max Moiseev
 Review Manager: TBD
 Status: Awaiting implementation
 Introduction
 
 We propose to deprecate the controversial version of a Sequence.flatMap 
 method and provide the same functionality under a different, and 
 potentially more descriptive, name.
 
 Motivation
 
 The Swift standard library currently defines 3 distinct overloads for 
 flatMap:
 
 Sequence.flatMap(_: (Element) -> S) -> [S.Element]
 where S : Sequence
 Optional.flatMap(_: (Wrapped) -> U?) -> U?
 Sequence.flatMap(_: (Element) -> U?) -> [U]
 The last one, despite being useful in certain situations, can be (and 
 often is) misused. Consider the following snippet:
 
 struct Person {
   var age: Int
   var name: String
 }
 
 func getAges(people: [Person]) -> [Int] {
   return people.flatMap { $0.age }
 }
 What happens inside getNames is: thanks to the implicit promotion to 
 Optional, the result of the closure gets wrapped into a .some, then 
 immediately unwrapped by the implementation of flatMap, and appended to 
 the result array. All this unnecessary wrapping and unwrapping can be 
 easily avoided by just using map instead.
 
 func getAges(people: [Person]) -> [Int] {
   return people.map { $0.age }
 }
 It gets even worse when we consider future code modifications, like the 
 one where Swift 4 introduced a Stringconformance to the Collection 
 protocol. The following code used to compile (due to the flatMap overload 
 in question).
 
 func getNames(people: [Person]) -> [String] {
   return people.flatMap { $0.name }
 }
 But it no longer does, because now there is a better overload that does 
 not involve implicit promotion. In this particular case, the compiler 
 error would be obvious, as it would point at the same line where flatMap 
 is used. Imagine however if it was just a let names = people.flatMap { 
 $0.name } statement, and the names variable were used elsewhere. The 
 compiler error would be misleading.
 
 Proposed solution
 
 We propose to deprecate the controversial overload of flatMap and 
 re-introduce the same functionality under a new name. The name being 
 filteredMap(_:) as we believe it best describes the intent of this 
 function.
 
 For reference, here are the alternative names from other languages:
 
 Haskell, Idris 
 mapMaybe :: (a -> Maybe b) -> [a] -> [b]
 Ocaml (Core and Batteries)
  filter_map : 'a t -> f:('a -> 'b option) 
 -> 'b t
 F#
  List.choose : ('T -> 'U option) -> 'T list -> 'U list
 Rust
  fn filter_map(self, f: F) -> FilterMap
  
 where F: FnMut(Self::Item) -> Option
 Scala 
 def collect[B](pf: PartialFunction[A, B]): List[B]
 Source compatibility
 
 Since the old 

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[Max Moiseev via swift-evolution]

It occurred to me that filteringMap(_:) should be even more descriptive, still 
conform to the guidelines, although similarly unprecedented and un-googlable.

Max

> On Oct 23, 2017, at 3:52 PM, Xiaodi Wu  wrote:
> 
> +1 in general. As to the name: since 'map' is used as a term of art, 
> 'filterMap' seems superior to 'filteredMap', which half follows naming 
> guidelines and half is a term of art; neither is immediately comprehensible 
> but 'filterMap' can be googled and has precedents in other languages.
> On Mon, Oct 23, 2017 at 17:24 BJ Homer via swift-evolution 
> > wrote:
> I strongly agree! In fact, I just started writing up a similar proposal the 
> other day, but hadn’t had time to finish it yet.
> 
> The current name for this particular filtering variant is not particularly 
> descriptive. It’s certainly not obvious to newcomers that ‘flatMap’ will 
> filter out results. And it’s not true to the existing usage of ‘flatMap' from 
> other languages; you have to really squint at it to see how any “flattening” 
> is happening at all.
> 
> So yes, a big +1 from me. Thanks!
> 
> -BJ Homer
> 
>> On Oct 23, 2017, at 4:15 PM, Max Moiseev via swift-evolution 
>> > wrote:
>> 
>> Hi swift-evolution!
>> 
>> I would like to propose the following change to the standard library:
>> 
>> deprecate `Sequence.flatMap(_: (Element) -> U?) -> [U]` and make this 
>> functionality available under a new name `Sequence.filteredMap(_:)`.
>> 
>> The draft is available at 
>> https://gist.github.com/moiseev/2f36376c8ef4c2b1273cff0bfd9c3b95 
>>  and is 
>> included below for your convenience.
>> 
>> Max
>> 
>> Introduce Sequence.filteredMap(_:)
>> 
>> Proposal: SE- 
>> Authors: Max Moiseev 
>> Review Manager: TBD
>> Status: Awaiting implementation
>>  
>> Introduction
>> 
>> We propose to deprecate the controversial version of a Sequence.flatMap 
>> method and provide the same functionality under a different, and potentially 
>> more descriptive, name.
>> 
>>  
>> Motivation
>> 
>> The Swift standard library currently defines 3 distinct overloads for 
>> flatMap:
>> 
>> Sequence.flatMap(_: (Element) -> S) -> [S.Element]
>> where S : Sequence
>> Optional.flatMap(_: (Wrapped) -> U?) -> U?
>> Sequence.flatMap(_: (Element) -> U?) -> [U]
>> The last one, despite being useful in certain situations, can be (and often 
>> is) misused. Consider the following snippet:
>> 
>> struct Person {
>>   var age: Int
>>   var name: String
>> }
>> 
>> func getAges(people: [Person]) -> [Int] {
>>   return people.flatMap { $0.age }
>> }
>> What happens inside getNames is: thanks to the implicit promotion to 
>> Optional, the result of the closure gets wrapped into a .some, then 
>> immediately unwrapped by the implementation of flatMap, and appended to the 
>> result array. All this unnecessary wrapping and unwrapping can be easily 
>> avoided by just using map instead.
>> 
>> func getAges(people: [Person]) -> [Int] {
>>   return people.map { $0.age }
>> }
>> It gets even worse when we consider future code modifications, like the one 
>> where Swift 4 introduced a Stringconformance to the Collection protocol. The 
>> following code used to compile (due to the flatMap overload in question).
>> 
>> func getNames(people: [Person]) -> [String] {
>>   return people.flatMap { $0.name }
>> }
>> But it no longer does, because now there is a better overload that does not 
>> involve implicit promotion. In this particular case, the compiler error 
>> would be obvious, as it would point at the same line where flatMap is used. 
>> Imagine however if it was just a let names = people.flatMap { $0.name 
>>  } statement, and the names variable were used elsewhere. 
>> The compiler error would be misleading.
>> 
>>  
>> Proposed
>>  solution
>> 
>> We propose to deprecate the controversial overload of flatMap and 
>> re-introduce the same functionality under a new name. The name being 
>> filteredMap(_:) as we believe it best describes the intent of this function.
>> 
>> For reference, here are the alternative names from other languages:
>> 
>> Haskell, Idris 
>> mapMaybe :: (a -> Maybe b) -> [a] -> [b]
>> Ocaml (Core and Batteries)
>>  filter_map : 'a t -> f:('a -> 'b option) -> 
>> 'b t
>> F#
>>  List.choose : ('T -> 'U option) -> 'T list -> 'U list
>> Rust
>>  fn filter_map(self, f: F) -> FilterMap
>>  where F: 
>> FnMut(Self::Item) -> Option
>> Scala 
>> def collect[B](pf: PartialFunction[A, B]): List[B]

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[Xiaodi Wu via swift-evolution]

On Mon, Oct 23, 2017 at 6:11 PM, Braden Scothern 
wrote:

> The reason `flatMap(_:)` has its name is for code like this:
>
> ```
> let nestedArray = [[1, 2, 3], [4, 5, 6]]
> let flatArray = nestedArray.flatMap {
> $0
> }
>
> print(flatArray) // prints [1, 2, 3, 4, 5, 6]
>
> let anotherNestedArrays = [[[1, 2], [3, 4]], [[5, 6], [7, 8]]]
> let anotherFlatArray = anotherNestedArray.flatMap {
> $0
> }
>
> print(anotherFlatArray) // prints [[1, 2], [3, 4], [5, 6], [7, 8]]
> ```
>
> Do your examples from other languages have this behavior of flattening
> nested sequences by 1 layer? Do you think it makes sense to have this
> effect as part of your proposed rename?
>
> I feel like the name `filteredMap(_:)` implies that the result should keep
> the same structure as the original Sequence type which doesn't allow for
> the flattening.
>
> If these 2 pieces of functionality weren't already a part of one function
> or if you proposal had a good solution to address this other part
> functionality, I would be accepting of a name change. I haven't ever been a
> fan of flatMap(_:) having 2 jobs, but it has been this way since Swift 1 or
> 2.
>

`flatMap` is not going away or being renamed. One particular overload is
being renamed so that the other overloads work as expected.


> Also, I don't think the name `filterMap` makes sense with Swift naming
> conventions. To me it implies that you are going to map in place vs the
> filtered makes it clear you are creating a new Array to return. I really
> like the sort() vs sorted() naming convention that is already the standard
> for Swift code and would rather any name changes stick to that.
>

`map`, `filter` and `flatMap` are settled exceptions to the Swift naming
conventions because they are terms of art, and that's not changing going
forward.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[Braden Scothern via swift-evolution]

The reason `flatMap(_:)` has its name is for code like this:

```
let nestedArray = [[1, 2, 3], [4, 5, 6]]
let flatArray = nestedArray.flatMap {
$0
}

print(flatArray) // prints [1, 2, 3, 4, 5, 6]

let anotherNestedArrays = [[[1, 2], [3, 4]], [[5, 6], [7, 8]]]
let anotherFlatArray = anotherNestedArray.flatMap {
$0
}

print(anotherFlatArray) // prints [[1, 2], [3, 4], [5, 6], [7, 8]]
```

Do your examples from other languages have this behavior of flattening
nested sequences by 1 layer? Do you think it makes sense to have this
effect as part of your proposed rename?

I feel like the name `filteredMap(_:)` implies that the result should keep
the same structure as the original Sequence type which doesn't allow for
the flattening.

If these 2 pieces of functionality weren't already a part of one function
or if you proposal had a good solution to address this other part
functionality, I would be accepting of a name change. I haven't ever been a
fan of flatMap(_:) having 2 jobs, but it has been this way since Swift 1 or
2.


Also, I don't think the name `filterMap` makes sense with Swift naming
conventions. To me it implies that you are going to map in place vs the
filtered makes it clear you are creating a new Array to return. I really
like the sort() vs sorted() naming convention that is already the standard
for Swift code and would rather any name changes stick to that.

On Mon, Oct 23, 2017 at 4:52 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 in general. As to the name: since 'map' is used as a term of art,
> 'filterMap' seems superior to 'filteredMap', which half follows naming
> guidelines and half is a term of art; neither is immediately comprehensible
> but 'filterMap' can be googled and has precedents in other languages.
>
> On Mon, Oct 23, 2017 at 17:24 BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I strongly agree! In fact, I just started writing up a similar proposal
>> the other day, but hadn’t had time to finish it yet.
>>
>> The current name for this particular filtering variant is not
>> particularly descriptive. It’s certainly not obvious to newcomers that
>> ‘flatMap’ will filter out results. And it’s not true to the existing usage
>> of ‘flatMap' from other languages; you have to really squint at it to see
>> how any “flattening” is happening at all.
>>
>> So yes, a big +1 from me. Thanks!
>>
>> -BJ Homer
>>
>> On Oct 23, 2017, at 4:15 PM, Max Moiseev via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Hi swift-evolution!
>>
>> I would like to propose the following change to the standard library:
>>
>> deprecate `Sequence.flatMap(_: (Element) -> U?) -> [U]` and make this
>> functionality available under a new name `Sequence.filteredMap(_:)`.
>>
>> The draft is available at https://gist.github.com/moiseev/
>> 2f36376c8ef4c2b1273cff0bfd9c3b95 and is included below for your
>> convenience.
>>
>> Max
>>
>> Introduce Sequence.filteredMap(_:)
>>
>>- Proposal: SE- 
>>- Authors: Max Moiseev 
>>- Review Manager: TBD
>>- Status: Awaiting implementation
>>
>>
>> 
>> Introduction
>>
>> We propose to deprecate the controversial version of a Sequence.flatMap 
>> method
>> and provide the same functionality under a different, and potentially more
>> descriptive, name.
>>
>> 
>> Motivation
>>
>> The Swift standard library currently defines 3 distinct overloads for
>> flatMap:
>>
>> Sequence.flatMap(_: (Element) -> S) -> [S.Element]
>> where S : SequenceOptional.flatMap(_: (Wrapped) -> U?) -> 
>> U?Sequence.flatMap(_: (Element) -> U?) -> [U]
>>
>> The last one, despite being useful in certain situations, can be (and
>> often is) misused. Consider the following snippet:
>>
>> struct Person {
>>   var age: Int
>>   var name: String
>> }
>> func getAges(people: [Person]) -> [Int] {
>>   return people.flatMap { $0.age }
>> }
>>
>> What happens inside getNames is: thanks to the implicit promotion to
>> Optional, the result of the closure gets wrapped into a .some, then
>> immediately unwrapped by the implementation of flatMap, and appended to
>> the result array. All this unnecessary wrapping and unwrapping can be
>> easily avoided by just using map instead.
>>
>> func getAges(people: [Person]) -> [Int] {
>>   return people.map { $0.age }
>> }
>>
>> It gets even worse when we consider future code modifications, like the
>> one where Swift 4 introduced a Stringconformance to the Collection protocol.
>> The following code used to compile (due to the flatMap overload in
>> question).
>>
>> func getNames(people: [Person]) -> [String] {
>>   return people.flatMap { $0.name }
>> }
>>
>> But it no longer does, because now there is a better overload 

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[Xiaodi Wu via swift-evolution]

+1 in general. As to the name: since 'map' is used as a term of art,
'filterMap' seems superior to 'filteredMap', which half follows naming
guidelines and half is a term of art; neither is immediately comprehensible
but 'filterMap' can be googled and has precedents in other languages.
On Mon, Oct 23, 2017 at 17:24 BJ Homer via swift-evolution <
swift-evolution@swift.org> wrote:

> I strongly agree! In fact, I just started writing up a similar proposal
> the other day, but hadn’t had time to finish it yet.
>
> The current name for this particular filtering variant is not particularly
> descriptive. It’s certainly not obvious to newcomers that ‘flatMap’ will
> filter out results. And it’s not true to the existing usage of ‘flatMap'
> from other languages; you have to really squint at it to see how any
> “flattening” is happening at all.
>
> So yes, a big +1 from me. Thanks!
>
> -BJ Homer
>
> On Oct 23, 2017, at 4:15 PM, Max Moiseev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi swift-evolution!
>
> I would like to propose the following change to the standard library:
>
> deprecate `Sequence.flatMap(_: (Element) -> U?) -> [U]` and make this
> functionality available under a new name `Sequence.filteredMap(_:)`.
>
> The draft is available at
> https://gist.github.com/moiseev/2f36376c8ef4c2b1273cff0bfd9c3b95 and is
> included below for your convenience.
>
> Max
>
> Introduce Sequence.filteredMap(_:)
>
>- Proposal: SE- 
>- Authors: Max Moiseev 
>- Review Manager: TBD
>- Status: Awaiting implementation
>
>
> 
> Introduction
>
> We propose to deprecate the controversial version of a Sequence.flatMap method
> and provide the same functionality under a different, and potentially more
> descriptive, name.
>
> 
> Motivation
>
> The Swift standard library currently defines 3 distinct overloads for
> flatMap:
>
> Sequence.flatMap(_: (Element) -> S) -> [S.Element]
> where S : SequenceOptional.flatMap(_: (Wrapped) -> U?) -> 
> U?Sequence.flatMap(_: (Element) -> U?) -> [U]
>
> The last one, despite being useful in certain situations, can be (and
> often is) misused. Consider the following snippet:
>
> struct Person {
>   var age: Int
>   var name: String
> }
> func getAges(people: [Person]) -> [Int] {
>   return people.flatMap { $0.age }
> }
>
> What happens inside getNames is: thanks to the implicit promotion to
> Optional, the result of the closure gets wrapped into a .some, then
> immediately unwrapped by the implementation of flatMap, and appended to
> the result array. All this unnecessary wrapping and unwrapping can be
> easily avoided by just using map instead.
>
> func getAges(people: [Person]) -> [Int] {
>   return people.map { $0.age }
> }
>
> It gets even worse when we consider future code modifications, like the
> one where Swift 4 introduced a Stringconformance to the Collection protocol.
> The following code used to compile (due to the flatMap overload in
> question).
>
> func getNames(people: [Person]) -> [String] {
>   return people.flatMap { $0.name }
> }
>
> But it no longer does, because now there is a better overload that does
> not involve implicit promotion. In this particular case, the compiler error
> would be obvious, as it would point at the same line where flatMap is
> used. Imagine however if it was just a let names = people.flatMap { $
> 0.name } statement, and the names variable were used elsewhere. The
> compiler error would be misleading.
>
> Proposed
> solution
>
> We propose to deprecate the controversial overload of flatMap and
> re-introduce the same functionality under a new name. The name being
> filteredMap(_:) as we believe it best describes the intent of this
> function.
>
> For reference, here are the alternative names from other languages:
>
>- Haskell, Idris  mapMaybe :: (a -> Maybe b) -> [a] -> [b]
>- Ocaml (Core and Batteries)  filter_map : 'a t -> f:('a -> 'b option)
>-> 'b t
>- F#  List.choose : ('T -> 'U option) -> 'T list -> 'U list
>- Rust  fn filter_map(self, f: F) -> FilterMap where F:
>FnMut(Self::Item) -> Option
>- Scala  def collect[B](pf: PartialFunction[A, B]): List[B]
>
>
> Source
> compatibility
>
> Since the old function will still be available (although deprecated) all
> the existing code will compile, producing a deprecation warning and a
> fix-it.
>
> Effect
> on ABI stability
>
> This is an additive API change, and does not affect ABI stability.
>
> 

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[BJ Homer via swift-evolution]

I strongly agree! In fact, I just started writing up a similar proposal the 
other day, but hadn’t had time to finish it yet.

The current name for this particular filtering variant is not particularly 
descriptive. It’s certainly not obvious to newcomers that ‘flatMap’ will filter 
out results. And it’s not true to the existing usage of ‘flatMap' from other 
languages; you have to really squint at it to see how any “flattening” is 
happening at all.

So yes, a big +1 from me. Thanks!

-BJ Homer

> On Oct 23, 2017, at 4:15 PM, Max Moiseev via swift-evolution 
>  wrote:
> 
> Hi swift-evolution!
> 
> I would like to propose the following change to the standard library:
> 
> deprecate `Sequence.flatMap(_: (Element) -> U?) -> [U]` and make this 
> functionality available under a new name `Sequence.filteredMap(_:)`.
> 
> The draft is available at 
> https://gist.github.com/moiseev/2f36376c8ef4c2b1273cff0bfd9c3b95 
>  and is 
> included below for your convenience.
> 
> Max
> 
> Introduce Sequence.filteredMap(_:)
> 
> Proposal: SE- 
> Authors: Max Moiseev 
> Review Manager: TBD
> Status: Awaiting implementation
>  
> Introduction
> 
> We propose to deprecate the controversial version of a Sequence.flatMap 
> method and provide the same functionality under a different, and potentially 
> more descriptive, name.
> 
>  
> Motivation
> 
> The Swift standard library currently defines 3 distinct overloads for flatMap:
> 
> Sequence.flatMap(_: (Element) -> S) -> [S.Element]
> where S : Sequence
> Optional.flatMap(_: (Wrapped) -> U?) -> U?
> Sequence.flatMap(_: (Element) -> U?) -> [U]
> The last one, despite being useful in certain situations, can be (and often 
> is) misused. Consider the following snippet:
> 
> struct Person {
>   var age: Int
>   var name: String
> }
> 
> func getAges(people: [Person]) -> [Int] {
>   return people.flatMap { $0.age }
> }
> What happens inside getNames is: thanks to the implicit promotion to 
> Optional, the result of the closure gets wrapped into a .some, then 
> immediately unwrapped by the implementation of flatMap, and appended to the 
> result array. All this unnecessary wrapping and unwrapping can be easily 
> avoided by just using map instead.
> 
> func getAges(people: [Person]) -> [Int] {
>   return people.map { $0.age }
> }
> It gets even worse when we consider future code modifications, like the one 
> where Swift 4 introduced a Stringconformance to the Collection protocol. The 
> following code used to compile (due to the flatMap overload in question).
> 
> func getNames(people: [Person]) -> [String] {
>   return people.flatMap { $0.name }
> }
> But it no longer does, because now there is a better overload that does not 
> involve implicit promotion. In this particular case, the compiler error would 
> be obvious, as it would point at the same line where flatMap is used. Imagine 
> however if it was just a let names = people.flatMap { $0.name } statement, 
> and the names variable were used elsewhere. The compiler error would be 
> misleading.
> 
>  
> Proposed
>  solution
> 
> We propose to deprecate the controversial overload of flatMap and 
> re-introduce the same functionality under a new name. The name being 
> filteredMap(_:) as we believe it best describes the intent of this function.
> 
> For reference, here are the alternative names from other languages:
> 
> Haskell, Idris 
> mapMaybe :: (a -> Maybe b) -> [a] -> [b]
> Ocaml (Core and Batteries)
>  filter_map : 'a t -> f:('a -> 'b option) -> 'b t
> F#
>  List.choose : ('T -> 'U option) -> 'T list -> 'U list
> Rust
>  fn filter_map(self, f: F) -> FilterMap
>  where F: 
> FnMut(Self::Item) -> Option
> Scala 
> def collect[B](pf: PartialFunction[A, B]): List[B]
>  
> Source
>  compatibility
> 
> Since the old function will still be available (although deprecated) all the 
> existing code will compile, producing a deprecation warning and a fix-it.
> 
>  
> Effect
>  on ABI stability
> 
> This is an additive API change, and does not affect ABI stability.
> 
>  
> Effect
>  on API resilience
> 
> Ideally, the deprecated flatMap overload would not exist at the time when ABI 
> stability is declared, but in the worst case, it will be available in a 
> deprecated form from a library post-ABI stability.
> 
>  
> 

[swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

[Max Moiseev via swift-evolution]

Hi swift-evolution!

I would like to propose the following change to the standard library:

deprecate `Sequence.flatMap(_: (Element) -> U?) -> [U]` and make this 
functionality available under a new name `Sequence.filteredMap(_:)`.

The draft is available at 
https://gist.github.com/moiseev/2f36376c8ef4c2b1273cff0bfd9c3b95 
 and is 
included below for your convenience.

Max

Introduce Sequence.filteredMap(_:)

Proposal: SE- 
Authors: Max Moiseev 
Review Manager: TBD
Status: Awaiting implementation
 
Introduction

We propose to deprecate the controversial version of a Sequence.flatMap method 
and provide the same functionality under a different, and potentially more 
descriptive, name.

 
Motivation

The Swift standard library currently defines 3 distinct overloads for flatMap:

Sequence.flatMap(_: (Element) -> S) -> [S.Element]
where S : Sequence
Optional.flatMap(_: (Wrapped) -> U?) -> U?
Sequence.flatMap(_: (Element) -> U?) -> [U]
The last one, despite being useful in certain situations, can be (and often is) 
misused. Consider the following snippet:

struct Person {
  var age: Int
  var name: String
}

func getAges(people: [Person]) -> [Int] {
  return people.flatMap { $0.age }
}
What happens inside getNames is: thanks to the implicit promotion to Optional, 
the result of the closure gets wrapped into a .some, then immediately unwrapped 
by the implementation of flatMap, and appended to the result array. All this 
unnecessary wrapping and unwrapping can be easily avoided by just using map 
instead.

func getAges(people: [Person]) -> [Int] {
  return people.map { $0.age }
}
It gets even worse when we consider future code modifications, like the one 
where Swift 4 introduced a Stringconformance to the Collection protocol. The 
following code used to compile (due to the flatMap overload in question).

func getNames(people: [Person]) -> [String] {
  return people.flatMap { $0.name }
}
But it no longer does, because now there is a better overload that does not 
involve implicit promotion. In this particular case, the compiler error would 
be obvious, as it would point at the same line where flatMap is used. Imagine 
however if it was just a let names = people.flatMap { $0.name } statement, and 
the names variable were used elsewhere. The compiler error would be misleading.

 
Proposed
 solution

We propose to deprecate the controversial overload of flatMap and re-introduce 
the same functionality under a new name. The name being filteredMap(_:) as we 
believe it best describes the intent of this function.

For reference, here are the alternative names from other languages:

Haskell, Idris 
mapMaybe :: (a -> Maybe b) -> [a] -> [b]
Ocaml (Core and Batteries)
 filter_map : 'a t -> f:('a -> 'b option) -> 'b t
F#
 List.choose : ('T -> 'U option) -> 'T list -> 'U list
Rust
 fn filter_map(self, f: F) -> FilterMap
 where F: 
FnMut(Self::Item) -> Option
Scala 
def collect[B](pf: PartialFunction[A, B]): List[B]
 
Source
 compatibility

Since the old function will still be available (although deprecated) all the 
existing code will compile, producing a deprecation warning and a fix-it.

 
Effect
 on ABI stability

This is an additive API change, and does not affect ABI stability.

 
Effect
 on API resilience

Ideally, the deprecated flatMap overload would not exist at the time when ABI 
stability is declared, but in the worst case, it will be available in a 
deprecated form from a library post-ABI stability.

 
Alternatives
 considered

It was attempted in the past to warn about this kind of misuse and do the right 
thing instead by means of a deprecated overload with a non-optional-returning 
closure. The attempt failed due to another implicit promotion (this time to 
Any).

The following alternative names for this function were considered:

mapNonNil(_:)
 Does not communicate what happens to nil’s
mapSome(_:)
 Reads more like «map some elements of the sequence, but not the 
others» rather than «process only the ones that produce an Optional.some»
filterMap(_:) 
Does not really follow the naming guidelines and doesn’t seem to 
be common enough to be considered a term of art.

___
swift-evolution mailing list

Re: [swift-evolution] [SPM] Roadmap?

[Kelvin Ma via swift-evolution]

Since this list is dominated by iDevice developers, as a Linux support
advocate I’d like to see better support for including and linking C
libraries (please no more shim hacks), and a swift test command that can
execute arbitrary testing code. Since library ABI is something that we’re
trying to iron out for Swift 5, I’d also like to see a SPM that helps us
manage symbol versioning and availability.

On Mon, Oct 23, 2017 at 2:16 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> I would like Xcode integration 
>
> -- Howard.
>
> On 24 Oct 2017, at 4:43 am, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’d be happy if we’d get iOS support and submodules :)
>
>
> Am 23. Oktober 2017 um 19:41:37, Jean-Christophe Pastant via
> swift-evolution (swift-evolution@swift.org) schrieb:
>
> Hi,
>
> Is there any news about features that are willling to be integrated into
> SPM 5?
> Those I see the most relevant:
> - iOS support
> - Some kind of configuration/settings support (debug, release, ...)
>
> I'd like to hear about it from maintainers, especially if there's a
> priority order we should follow.
>
> Regards,
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [SPM] Roadmap?

[Howard Lovatt via swift-evolution]

I would like Xcode integration 

-- Howard. 

> On 24 Oct 2017, at 4:43 am, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’d be happy if we’d get iOS support and submodules :)
> 
> 
> Am 23. Oktober 2017 um 19:41:37, Jean-Christophe Pastant via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> Hi,
>> 
>> Is there any news about features that are willling to be integrated into SPM 
>> 5?
>> Those I see the most relevant:
>> - iOS support
>> - Some kind of configuration/settings support (debug, release, ...)
>> 
>> I'd like to hear about it from maintainers, especially if there's a priority 
>> order we should follow.
>> 
>> Regards,
>> 
>> 
>> ___
>> 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] [SPM] Roadmap?

[Adrian Zubarev via swift-evolution]

I’d be happy if we’d get iOS support and submodules :)


Am 23. Oktober 2017 um 19:41:37, Jean-Christophe Pastant via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority 
order we should follow.

Regards,


___
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] [SPM] Roadmap?

[Jean-Christophe Pastant via swift-evolution]

Hi,

Is there any news about features that are willling to be integrated into
SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a
priority order we should follow.

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

Re: [swift-evolution] Support for a KeyCodingStrategy option in JSONEncoder and JSONDecoder

[Mike Kluev via swift-evolution]

on 19 Oct 2017 11:21:39 -0700 Eagle Offshore  wrote:

Yes, in general, I think Codable is a poor solution for json decoding just
> like I never used NSCoding to convert JSON to and from objects.  It feels
> clumsy.
>
> I found it a much better solution to add a category to NSObject that had
>
> -(NSData*)toJSONRepresentationWithMappings:(NSDictionary*)d
> +()fromJSONRepresentation:(NSData*) mappings:(NSDictionary*)d
>
> where mappings might be { @"firstName": @"first_name", etc }
>
> and was simple to write a general solution using introspection and KVC.
>
> Codable is a limited one trick pony that would be trivial to write as a
> trait or extension if Swift provided the more profound thing -
> introspection and reflection.  A whole world of opportunities would open up
> with that and we could stop wasting time on Codable and KeyPath - neither
> of which is that useful when working with string data from the wild.
>

i found Codable very useful. when you need to translate the keys it's a bit
awkward and looks "unfinished" but if you don't need the translation you
literally write no code at all which is good.

having Codable does not contradict having introspection /
reflection. general (or shall we say custom) approaches that use
introspection / reflection tend to work much slower (from Objective-C
experience). i have no data if Codable is performant in these regards but
at least it has a potential to be more optimal than a general solution
based on introspection / reflection.

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