Re: [swift-evolution] [Review] SE-188 Make stdlib index types Hashable

[Howard Lovatt via swift-evolution]

Proposal link:
https://github.com/apple/swift-evolution/blob/master/
proposals/0188-stdlib-index-types-hashable.md

• What is your evaluation of the proposal?

+1 but would like it to further and require all index types to be Hashable.

• Is the problem being addressed significant enough to warrant a change to
Swift?

It has been a problem for me in the past, however just requiring the
standard library ones to be hashable would solve the problem of third party
libraries, therefore suggest all hashable.

• Does this proposal fit well with the feel and direction of Swift?

Yes, this is the sort of thing that needs finalising before ABI stability
else we will be stuck with a problem.

• If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

Yes, Java, Scala, etc. Most languages have a hashable index so you can have
a set on indices etc.

• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Have read the review and have also implemented my own collections, which
used hashable indices.

  -- Howard.

On 9 November 2017 at 12:55, Ben Cohen via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello, Swift community!
>
> The review of “SE-0188: Make stdlib index types Hashable” begins now and
> runs through November 14th, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0188-stdlib-index-types-hashable.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 me as 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/0188-stdlib-index-types-hashable.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
>
>
> As always, thank you for contributing to the evolution of Swift.
>
> Ben Cohen
> Review Manager
>
>
>
>
> ___
> 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] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

Glad to see people working on this! I already have a functioning
almost-pure Swift PNG library , and a JPEG
library  is a month or two away. I’m glad
someone is hacking away at some sort of rasterization engine (like cairo
for C/C++). The way I see a lot of these graphics libraries is they live in
a sort of “tech tree” and a lot of them depend on support higher up the
tree, like in a video game. For now we seem to be filling in a lot of the
top row with C libraries which doesn’t always work too well (like in the
case of zlib).

   Rasterizer  File I/O, path manipulation ——+——— LZ77
compression
[{cairo equiv.}][{file manager lib}, URL
]| [{zlib equiv.}]
|  | |
| +—+——+++——+
| | |  |||  |
|XML  HTML  TTF/OTF   JPEG  PNG   GZIP
|[swiftxml ]  [{???}]
[{???}]  [JPEG ]   [MaxPNG
]  [{archiving lib}]
|| ||
+|———+—+———++
+——+—+   | |
   | | |
  SVG  Text renderer  WOFF
[{???}] [{freetype equiv.}]  [{???}]

On Thu, Nov 9, 2017 at 9:25 AM, Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:

> Sound great!
>
> Last week I started working on a pure-swift graphics library, one goal
> being fast server-side graphics manipulations, and already have .png
> decode/encode, and quadratic bezier curve stroking implemented, slowly, and
> poorly.  I’m working on TrueType fonts right now, and intend to open it to
> other developers once the basic architecture is refined.  I intend to add
> SVG and JPEG support as well.  It seems like if there is a “swift-community
> blessed geometry library”, this would be a natural extension of that, or at
> least depend on it.
>
> Much of this depends on compression support, which I’ve already published
> a first cut of at https://github.com/benspratling4/
> SwiftFoundationCompression .  The goal there was a more “foundation” idea
> of compression than competing libraries, but it suffers from a lack of
> streaming support.
>
> I would absolutely love a “BigNum” library.  Several encryption packages
> out there would benefit from it as well.  It seems arithmetic compression
> libraries would benefit, too.  Other useful Numeric types would include
> rational fractions, fixed-point, and short floats (Float16 is what Apple
> now thinks the future of images is, right?).  I’m happy to contribute; I
> end up writing those in a new language ever few years anyway.
>
> -Ben Spratling
>
>
> On Nov 7, 2017, at 12:54 PM, Dave DeLong via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Swift-Evolution,
> ...
>
> We propose to create an open-sourced "Non-Standard Library" effort that
> coexists with, coordinates with, and is blessed by the open source Swift
> development community. The "Non-Standard Library" will offer a
> well-curated, high-value collection of routines, types, and documentation
> to support Swift development on all platforms.
> …
>
>
> *Suggested Libraries*
>
> There are several areas we think that are ripe for improvement and
> implementation as a non-standard library, such as (but not limited to):
>
>- A BigNum library
>- A full-featured Random library
>- A simplified date/time library
>- A library for manipulating paths (that is not based on URL or String)
>- An expanded Swift-native Geometry library and so forth.
>
> The scope and extent of the sublibraries would be proposed and debated on
> a parallel Non-Standard Library Evolution development list.
>
>
>
> ___
> 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] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Thu, Nov 9, 2017 at 12:37 PM, Wallacy via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Em qui, 9 de nov de 2017 às 03:42, Ted Kremenek 
> escreveu:
>
>> These are some really interesting analogies.  How would you imagine the
>> community “governance” of these “plugins” (which I assume would be
>> libraries or packages) to be managed?
>>
>
> Pretty much like a TV/Games/etc community forums. The owner (In this case
> Apple/Core Team) invite some people to help (Moderators etc) to maintain
> the main project, look if everyone is follow the rules, etc.
>
> Also is similar as other opensource projects.
>
>
>> What does it mean for the “full community” to manage them, and provide
>> the rough guarantees you suggest?
>>
>
> NPM has thousands of projects, is impossible to check all of then. And
> besides be a good reference, here we have the opportunity do to something
> better... Because...Because...Because I believe we can ;)
>
> So what i expect?
>
> Lets make some assumptions here, just to play a little:
>
> Let assume we build a Indexer like IBM Swift Package Catalog (
> https://packagecatalog.com/ ) over Swift.org.
>
> And like Swift Source Compatibility Suite to be "indexed" the author of
> the project needs to send the request to be accepted.
>
> Lets assume the same rules as Compatibility Suite:
> Acceptance Criteria
>
> To be accepted into the Swift source compatibility test suite, a project
> must:
>
>1. Target Linux, macOS, or iOS/tvOS/watchOS device
>2. Be an *Xcode* or *Swift Package Manager* project (Carthage and
>CocoaPods are currently unsupported but are being explored to be supported
>in the future)
>3. Support building on either Linux or macOS
>4. Be contained in a publicly accessible git repository
>5. Maintain a project branch that builds against Swift 3.0
>compatibility mode and passes any unit tests
>6. Have maintainers who will commit to resolve issues in a timely
>manner
>7. Be compatible with the latest GM/Beta versions of *Xcode* and
>*swiftpm*
>8. Add value not already included in the suite
>9. Be licensed with one of the following permissive licenses:
>   - BSD
>   - MIT
>   - Apache License, version 2.0
>   - Eclipse Public License
>   - Mozilla Public License (MPL) 1.1
>   - MPL 2.0
>   - CDDL
>
> i’m okay with this as long as point 9 is changed to accept copyleft
licenses like GPL. currently this is a huge hole in the SSCS which i am
sure will cause issues down the road
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Mark Sands via swift-evolution]

+1

• What is your evaluation of the proposal?

I am highly in favor of this proposal. I have seen so many of my peers
struggle with custom types, like Result and Observable, that implement a
functional flatMap as opposed to the aforementioned flatMap that I've seen
create a barrier of learning. While my observation is anecdotal, it speaks
to an existing, greater churn to a journey of understanding as opposed to a
provisional swift migration.

• Is the problem being addressed significant enough to warrant a change to
Swift?

Yes.

• Does this proposal fit well with the feel and direction of Swift?

Yes.

• If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

This change will properly align the definition of flatMap across other
languages.

• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

A quick reading.

On Thu, Nov 9, 2017 at 6:18 PM, Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Nov 9, 2017, at 1:48 PM, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:
>
> The problem in the Doodads example is that *the name flatMap is used to
> identify two distinct intents*: concatenating arrays and filtering nils.
> One can argue that those two operations are, in some lofty abstract sense,
> if you squint, two instances of some more general pattern — but I don’t
> think it’s fair to say that they represent the same *intent*. These
> separate intents deserve separate names.
>
>
> They absolutely represent the same intent if you think of an optional as a
> collection of zero or one elements.
>
>
> This is precisely the “lofty abstract sense, if you squint” to which I was
> referring. I stand by that characterization. Just because there is a clever
> isomorphism between two types doesn’t mean people use them with equivalent
> intent.
>
> Splitting that hair aside, the point of that example code stands: using
> the same name for both flatMap variants causes the type checker to miss
> programmer errors it would otherwise catch. (And unlike the first
> motivating example in the proposal, the “warn on optional hoisting” feature
> would not help at all.)
>
> But as `Optional` does not conform to collection, I would suggest that the
> vast majority of of developers do _not_ think of them as a collection of
> zero or one elements. (I certainly don’t know any who naturally think of it
> that way.) We don’t treat Optional as a collection anywhere else in the
> API, and it seems odd to do so in just this one case.
>
>
> And, to be clear, the lack of Collection conformance by Optional is an
> active choice, not an omission.
>
> The “think of optionals as collections” explanation is a good way to help
> people who are confused by the overload. But an even better way would be to
> not have a confusing overload in the first place.
>
>
> Exactly so. A much crisper way of stating my sprawling argument.
>
> I’m personally grateful that Swift reminds me that, for example, I need
> the question mark in view.gestureRecognizers?.count. It would be
> maddening if view.gestureRecognizers.count compiled, and always returned
> either 0 or 1. Imagine it!
>
> view.gestureRecognizers.count  // returns 0
> view.gestureRecognizers = []
> view.gestureRecognizers.count  // now returns 1 (wat?)
> view.gestureRecognizers = [foo, bar, baz]
> view.gestureRecognizers.count  // still returns 1 (wat?!)
>
> That is a recipe for torches and pitchforks right there. Yet it is
> analogous to what flatMap currently does.
>
> Cheers,
>
> Paul
>
>
> ___
> 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] [swift-evolution-announce] [Review] SE-188 Make stdlib index types Hashable

[Brent Royal-Gordon via swift-evolution]

> On Nov 9, 2017, at 4:29 AM, Xiaodi Wu  wrote:
> 
> Why not? Specifically, why shouldn't we require `Hashable` conformance on 
> indices? Adding it would require changes to conforming types, sure, but 
> indices are already required to be `Equatable`, and `Hashable` conformance 
> just got really easy to add, and custom `Collection`s are a relatively rare 
> and advanced feature.
> 
> For a source-breaking change, that’s the wrong question to ask. It’s not “why 
> not,” but “why so”? It’s so easy to add the conformance, and any type can opt 
> into it so easily, what is the gain by forcing it and can it be justified as 
> a source-breaking change?


You're right that source-breaking changes need to be justified. What I would 
say is:

1. This proposal as written will require many conditional conformances; 
it would be better (and would allow us to fully implement it sooner) if they 
were unconditional.

2. Relying on `where` clauses does not help you in type-erased code. 
`AnyIndex` cannot conditionally conform to `Hashable` because it erases types, 
and it's not clear to me whether `AnyIndex` can be cleanly converted to 
`AnyHashable` or vice versa. This means code using type erasure may be awkward 
to write if it needs `Hashable` indices.

3. The `KeyPath` case discussed in this proposal is another example 
where ad-hoc `Hashable` indices cause trouble for type erasure (in that 
`KeyPath`s erase the types of the indices inside them). It would be very weird 
for `KeyPath`s to only support indices if they happen to also be `Hashable`.

4. `Hashable` conformance is extremely useful in general. It allows, 
among other features, use as a `Set` or `Dictionary` key, and apparently now 
use in `KeyPath` as well. Replacing an `Array` of indices with a `Set`, or 
switching from some other representation to a `KeyPath`, is the sort of change 
we would like generic algorithms to be able to make without breaking binary 
compatibility with their callers.

5. `Hashable` occupies a special place of importance among our standard 
protocols. In the past, we've occasionally discussed making it mandatory and 
impossible to opt out of; many languages actually do that. Even though we 
haven't, I've seen experts make flat statements along the lines of "All value 
types should conform to `Hashable`". This is not like requiring an index to be, 
say, `Strideable` or a `SignedInteger`.

6. The compiler can now automatically synthesize `Hashable` conformance 
for many simple types; this makes the burden of requiring a conformance 
unusually low.

7. I have written several custom collections, and it has never occurred 
to me to conform the index to `Hashable`, but now that it's been mentioned I 
realize that it would have been both easy and extremely useful to do so. My 
index types would already have been `Hashable` if the standard library had 
forced me to do so.

Basically, what it comes down to is, `Hashable` is very useful and there are 
not many plausible index designs which would have trouble supporting it. It is 
not absolutely necessary to make this change, but I think it would lead to 
better, more useful types with a fairly low burden.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

[Florent Vilmart via swift-evolution]

I really like this idea of scoped import, but I’m not sure it’s part of 
anything supported widely. I was about to suggest ‘namespaces’ but that’s not a 
thing in swift.

On Nov 9, 2017, 17:06 -0500, Rod Brown , wrote:
>
> > On 7 Nov 2017, at 6:24 am, Tony Parker via swift-evolution 
> >  wrote:
> >
> > Hi Florent,
> >
> > We definitely thought about this while designing the set of types with the 
> > Codable proposals.
> >
> > One serious concern was just how much API surface area there already is 
> > with Codable. If we open up the internal classes as well, we risk confusing 
> > the majority of people who are just adopting Codable with APIs that are 
> > intended only for the minority of people who are trying to create their own 
> > custom encoders and decoders.
> >
> > Any thoughts on how to mitigate this?
> >
> > - Tony
>
> I’ve been curious for some time about if we can do something about an opt-in 
> import in Swift?
>
> For example, currently UIGestureRecognizer in UIKit has “subclass only” 
> methods that are protected and opt in. Importing UIKit itself doesn’t bring 
> it in, and instead you need to specifically import 
> UIKit.UIGestureRecognizerSubclass.
>
> I realise this is a standalone case, but I’m wondering whether we can 
> generalise this into something we can propose, to actively support nested 
> scopes in the same way?
>
> This would lend well to disclosing the internals like this. It would avoid 
> users jumping straight for the internal types because they wouldn’t be there 
> with “import Foundation” - it would require something eg “import 
> Foundation.xyz”.
>
> Was this part of an earlier discussion of modules etc?
>
> - Rod
>
> >
> > > On Nov 3, 2017, at 9:58 AM, Florent Vilmart via swift-evolution 
> > >  wrote:
> > >
> > > At Swift Summit, we discussed with Joe and Jordan about opening up the 
> > > Encoder/Decoder classes in order to make the work of an encoder designer 
> > > easier.
> > >
> > > As I was working on an API project, I found myself into the situation of 
> > > needing to tweak so slightly the encoding strategy this required a full 
> > > copy/paste of the JSONEncoder.swift file and playing with the internals. 
> > > I also wanted to implement a simple QueryStringEncoder/Decoder that would 
> > > properly encode / decode a query string.
> > >
> > > The internally defined classes are proven a very powerful tool of 
> > > reflection as well, being able to collect / untransform a series of 
> > > containers safely into a strongly typed swift object.
> > >
> > > The pitch:
> > >
> > > - Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data
> > > - Make _JSONEncoder / _JSONDecoder open classes
> > > - Mark public all container implementations of UnkeyedEncodingContainers 
> > > etc...
> > > - Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't 
> > > conflict with JSONEncoder / JSONDecoder but also denotes they conform to 
> > > Encoder.
> > >
> > > Opening those API's isn't for the general Codable implementation, the 
> > > JSONEncoder/JSONDecoder should stay as-is but it's intended to reduce the 
> > > amount of boiler plate one would need to implement in order to provide 
> > > different serialization mechanism / strategy.
> > >
> > >
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > ___
> > 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: Remove default initialization of optional bindings

[Nathan Gray via swift-evolution]

On the other side, I'd say requiring explicit initialization to nil
increases the amount of busywork for the programmer for no good reason.  I
use it all the time and I would be pretty annoyed if it went away.  I would
be pretty shocked if most Swift users don't know that exists.

On Mon, Nov 6, 2017 at 2:33 PM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> Right now, the following two declarations are equivalent:
>
> struct S {
>   var x: Int?
> }
>
> struct S {
>   var x: Int? = nil
> }
>
> That is, mutable bindings of sugared optional type (but not Optional!)
> always have a default value of ‘nil’. This feature increases the surface
> area of the language for no good reason, and I would like to deprecate it
> in -swift-version 5 with a short proposal. Does anyone feel strongly about
> giving it up? I suspect most Swift users don’t even know it exists.
>
> Slava
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Functional Programmer, iOS Developer, Surfs Poorly
http://twitter.com/n8gray
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Paul Cantrell via swift-evolution]

> On Nov 9, 2017, at 1:48 PM, Ben Cohen via swift-evolution 
> > wrote:
> 
>> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution 
>> > wrote:
>> 
>> On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution 
>> > wrote:
>>> 
>>> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:
 The problem in the Doodads example is that the name flatMap is used to 
 identify two distinct intents: concatenating arrays and filtering nils. 
 One can argue that those two operations are, in some lofty abstract sense, 
 if you squint, two instances of some more general pattern — but I don’t 
 think it’s fair to say that they represent the same intent. These separate 
 intents deserve separate names.
>>> 
>>> They absolutely represent the same intent if you think of an optional as a 
>>> collection of zero or one elements.

This is precisely the “lofty abstract sense, if you squint” to which I was 
referring. I stand by that characterization. Just because there is a clever 
isomorphism between two types doesn’t mean people use them with equivalent 
intent.

Splitting that hair aside, the point of that example code stands: using the 
same name for both flatMap variants causes the type checker to miss programmer 
errors it would otherwise catch. (And unlike the first motivating example in 
the proposal, the “warn on optional hoisting” feature would not help at all.)

>> 
>> But as `Optional` does not conform to collection, I would suggest that the 
>> vast majority of of developers do _not_ think of them as a collection of 
>> zero or one elements. (I certainly don’t know any who naturally think of it 
>> that way.) We don’t treat Optional as a collection anywhere else in the API, 
>> and it seems odd to do so in just this one case.
> 
> And, to be clear, the lack of Collection conformance by Optional is an active 
> choice, not an omission.
> 
> The “think of optionals as collections” explanation is a good way to help 
> people who are confused by the overload. But an even better way would be to 
> not have a confusing overload in the first place.

Exactly so. A much crisper way of stating my sprawling argument.

I’m personally grateful that Swift reminds me that, for example, I need the 
question mark in view.gestureRecognizers?.count. It would be maddening if 
view.gestureRecognizers.count compiled, and always returned either 0 or 1. 
Imagine it!

view.gestureRecognizers.count  // returns 0
view.gestureRecognizers = []
view.gestureRecognizers.count  // now returns 1 (wat?)
view.gestureRecognizers = [foo, bar, baz]
view.gestureRecognizers.count  // still returns 1 (wat?!)

That is a recipe for torches and pitchforks right there. Yet it is analogous to 
what flatMap currently does.

Cheers,

Paul

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

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Ben Cohen via swift-evolution]

> On Nov 9, 2017, at 4:01 PM, Paul Cantrell  wrote:
> 
>  using the same name for both flatMap variants causes the type checker to 
> miss programmer errors

Not to mention, makes it do a lot more work, lengthening compile times 
(especially when mixed with closure and literal type inference… the 
combinations, they explode).


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

Re: [swift-evolution] SE-0187: Introduce Sequence.filterMap(_:)

[Sam Warner via swift-evolution]

What I meant by flagging the renaming of the generic `flatMap` to the more
specific-to-this-case `filterMap` is that all of the current uses of
`flatMap` share conceptual details: they all process whatever is in the
box, then perform one level of flattening.

This shared concept is hugely valuable, IMO, for people who are new to
Swift in being able to form an understanding of what these functions do,
and also for library authors who are creating box types and want
discoverable, intuitive API names.

This is the reason why I lean towards keeping `flatMap` and adding a
compiler warning for incorrect/redundant uses.

Cheers,

Sam

On Fri, 10 Nov 2017 at 05:43 BJ Homer  wrote:

>
> On Nov 9, 2017, at 11:35 AM, Tino Heth <2...@gmx.de> wrote:
>
>
> This proposal only proposes renaming the “filterNonesAndMap” variant
> (though that name is misleading, it would be “filterNonesAfterMapping” if
> anything); the other uses of flatMap will remain unchanged.
>
> … then it should be really right: As I learned in the thread, there is a
> map step before filter, and another map afterwards - so
> „filterNonesAfterMappingAndMap“ (that’s why I don’t like the use of the
> term „filter“ here — if you want an accurate name that contains this verb,
> it gets quite complicated…)
>
>
> But obviously “filterNonesAfterMappingAndMap” is not a name we’re going to
> end up with. You can argue that “filterMap” is not completely faithful to
> the internal implementation, but I think it’s clearly better than “flatMap”
> in this case, which is even *more* incorrect. I’m not opposed to finding
> a better name than “filterMap”, but so far I haven’t seen one.
>
> -BJ
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Lance Parker via swift-evolution]

The idea is that renaming this will nudge people into using map when 
appropriate.

> On Nov 9, 2017, at 1:45 PM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> - 1 I agree with Kevin Ballard. 
> 
> I think that it would be appropriate to nudge the user to use map instead. 
> 
> We already nudge people to use let over var so I think is sensible to do the 
> same for misuses of flatMap when map is sufficient.
> 
> Thanks!
> 
> 
>> On Nov 8, 2017, at 10:43 AM, John McCall via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Nov 8, 2017, at 1:20 PM, Kevin Ballard >> > wrote:
>>> 
>>> On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote:
 
> On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution 
> > wrote:
> 
> On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>>  
>> 
>> 
>> • What is your evaluation of the proposal?
> 
> This proposal is going to cause an insane amount of code churn. The 
> proposal suggests this overload of flatMap is used "in certain 
> circumstances", but in my experience it's more like 99% of all flatMaps 
> on sequences are to deal with optionals, not to flatten nested sequences.
> 
>> • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> I don't think so. It's a fairly minor issue, one that really only affects 
> new Swift programmers anyway rather than all users, and it will cause far 
> too much code churn to be worthwhile.
> 
> I'd much rather see a proposal to add a new @available type, something 
> like 'warning', that lets you attach an arbitrary warning message to a 
> call (which you can kind of do with 'deprecated' except that makes the 
> warning message claim the API is deprecated).
 
 As review manager, I generally try to avoid commenting on threads, but I 
 find this point interesting in a way that, if you don't mind, I'd like to 
 explore.
 
 Would this attribute not be a form of deprecation?  Certainly it acts to 
 discourage current and subsequent use, since every such use will evoke a 
 warning.
 
 Is the word "deprecation" just too strong?  Often we think of deprecated 
 APIs as being ones with more functional problems, like an inability to 
 report errors, or semantics that must have seemed like a good idea at the 
 time.  Here it's just that the API has a name we don't like, and perhaps 
 "deprecation" feels unnecessarily judgmental.
>>> 
>>> What I'm suggesting is that we don't change the API name at all. That's why 
>>> I don't want to use 'deprecated', because we're not actually deprecating 
>>> something. I'm just suggesting an alternative way of flagging cases where 
>>> the user tries to use flatMap but accidentally invokes optional hoisting, 
>>> and that's by making a new overload of flatMap that works for non-optional 
>>> (non-sequence) values and warns the user that what they're doing is better 
>>> done as a map. Using the 'deprecated' attribute for this would be confusing 
>>> because it would make it sound like flatMap itself is deprecated when it's 
>>> not.
>> 
>> I see.  Thanks.
>> 
>> John.
>> 
>>> 
 Also, more practically, it conflates a relatively unimportant suggestion — 
 that we should call the new method in order to make our code clearer — 
 with a more serious one — that we should revise our code to stop using a 
 problematic API.  Yes, the rename has a fix-it, but still: to the extent 
 that these things demand limited attention from the programmer, that 
 attention should clearly be focused on the latter set of problems.  
 Perhaps that sense of severity is something that an IDE should take into 
 consideration when reporting problems.
 
 What else would you have in mind for this warning?
>>> 
>>> The main use for this warning would be for adding overloads to methods that 
>>> take optionals in order to catch the cases where people invoke optional 
>>> hoisting, so we can tell them that there's a better way to handle it if 
>>> they don't have an optional. flatMap vs map is the obvious example, but I'm 
>>> sure there are other cases where we can do this too.
>>> 
>>> But there are also other once-off uses. For example, in the past I've 
>>> written a function that should only ever be used for debugging, so I marked 
>>> it as deprecated with a message saying 'remove this before committing your 
>>> code'. This warning would have been better done using the new 'warning' 
>>> attribute instead of as a 

Re: [swift-evolution] PITCH: Export _JSONEncoder / _JSONDecoder

[Rod Brown via swift-evolution]

> On 7 Nov 2017, at 6:24 am, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi Florent,
> 
> We definitely thought about this while designing the set of types with the 
> Codable proposals.
> 
> One serious concern was just how much API surface area there already is with 
> Codable. If we open up the internal classes as well, we risk confusing the 
> majority of people who are just adopting Codable with APIs that are intended 
> only for the minority of people who are trying to create their own custom 
> encoders and decoders.
> 
> Any thoughts on how to mitigate this?
> 
> - Tony

I’ve been curious for some time about if we can do something about an opt-in 
import in Swift?

For example, currently UIGestureRecognizer in UIKit has “subclass only” methods 
that are protected and opt in. Importing UIKit itself doesn’t bring it in, and 
instead you need to specifically import UIKit.UIGestureRecognizerSubclass.

I realise this is a standalone case, but I’m wondering whether we can 
generalise this into something we can propose, to actively support nested 
scopes in the same way?

This would lend well to disclosing the internals like this. It would avoid 
users jumping straight for the internal types because they wouldn’t be there 
with “import Foundation” - it would require something eg “import Foundation.xyz 
”.

Was this part of an earlier discussion of modules etc?

- Rod

> 
>> On Nov 3, 2017, at 9:58 AM, Florent Vilmart via swift-evolution 
>> > wrote:
>> 
>> At Swift Summit, we discussed with Joe and Jordan about opening up the 
>> Encoder/Decoder classes in order to make the work of an encoder designer 
>> easier.
>> 
>> As I was working on an API project, I found myself into the situation of 
>> needing to tweak so slightly the encoding strategy this required a full 
>> copy/paste of the JSONEncoder.swift file and playing with the internals. I 
>> also wanted to implement a simple QueryStringEncoder/Decoder that would 
>> properly encode / decode a query string.
>> 
>> The internally defined classes are proven a very powerful tool of reflection 
>> as well, being able to collect / untransform a series of containers safely 
>> into a strongly typed swift object.
>> 
>> The pitch:
>> 
>> - Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data
>> - Make _JSONEncoder / _JSONDecoder open classes
>> - Mark public all container implementations of UnkeyedEncodingContainers 
>> etc... 
>> - Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't 
>> conflict with JSONEncoder / JSONDecoder but also denotes they conform to 
>> Encoder. 
>> 
>> Opening those API's isn't for the general Codable implementation, the 
>> JSONEncoder/JSONDecoder should stay as-is but it's intended to reduce the 
>> amount of boiler plate one would need to implement in order to provide 
>> different serialization mechanism / strategy.
>>  
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> 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] JSONEncoder: Key strategies

[Rod Brown via swift-evolution]

I’m a fan. I understand that the CodingKey was the initial thought behind how 
to customise this, but a transformative approach is nice where there is a 
patterned update to keys.

Just one question: is there much performance impact by running through a key 
encoding strategy, even if it’s just a return in the case of `useDefaultKeys`?


> On 7 Nov 2017, at 7:54 am, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi everyone,
> 
> While we have no formal process at this time for proposals of changes to 
> Foundation-only code, I would still like to post one that we have run through 
> our internal process here for additional public comment.
> 
> Link to PR with proposal content:
> 
> https://github.com/apple/swift-corelibs-foundation/pull/1301 
> 
> 
> Link to implementation for the overlay:
> 
> https://github.com/apple/swift/pull/12779 
> 
> 
> Markdown follows.
> 
> Thanks,
> - Tony
> 
> # Key Strategies for JSONEncoder and JSONDecoder
> 
> * Proposal: SCLF-0001
> * Author(s): Tony Parker  >
> 
> # Related radars or Swift bugs
> 
> * > Snake case / Camel case 
> conversions for JSONEncoder/Decoder
> 
> # Revision history
> 
> * **v1** Initial version
> 
> ## Introduction
> 
> While early feedback for `JSONEncoder` and `JSONDecoder` has been very 
> positive, many developers have told us that they would appreciate a 
> convenience for converting between `snake_case_keys` and `camelCaseKeys` 
> without having to manually specify the key values for all types.
> 
> ## Proposed solution
> 
> `JSONEncoder` and `JSONDecoder` will gain new strategy properties to allow 
> for conversion of keys during encoding and decoding.
> 
> ```swift
> class JSONDecoder {
> /// The strategy to use for automatically changing the value of keys 
> before decoding.
> public enum KeyDecodingStrategy {
> /// Use the keys specified by each type. This is the default strategy.
> case useDefaultKeys
> 
> /// Convert from "snake_case_keys" to "camelCaseKeys" before 
> attempting to match a key with the one specified by each type.
> /// 
> /// The conversion to upper case uses `Locale.system`, also known as 
> the ICU "root" locale. This means the result is consistent regardless of the 
> current user's locale and language preferences.
> ///
> /// Converting from snake case to camel case:
> /// 1. Capitalizes the word starting after each `_`
> /// 2. Removes all `_`
> /// 3. Preserves starting and ending `_` (as these are often used to 
> indicate private variables or other metadata).
> /// For example, `one_two_three` becomes `oneTwoThree`. 
> `_one_two_three_` becomes `_oneTwoThree_`.
> ///
> /// - Note: Using a key decoding strategy has a nominal performance 
> cost, as each string key has to be inspected for the `_` character.
> case convertFromSnakeCase
> 
> /// Provide a custom conversion from the key in the encoded JSON to 
> the keys specified by the decoded types.
> /// The full path to the current decoding position is provided for 
> context (in case you need to locate this key within the payload). The 
> returned key is used in place of the last component in the coding path before 
> decoding.
> case custom(([CodingKey]) -> CodingKey)
> }
> 
> /// The strategy to use for decoding keys. Defaults to `.useDefaultKeys`.
> open var keyDecodingStrategy: KeyDecodingStrategy = .useDefaultKeys
> }
> 
> class JSONEncoder {
> /// The strategy to use for automatically changing the value of keys 
> before encoding.
> public enum KeyEncodingStrategy {
> /// Use the keys specified by each type. This is the default strategy.
> case useDefaultKeys
> 
> /// Convert from "camelCaseKeys" to "snake_case_keys" before writing 
> a key to JSON payload.
> ///
> /// Capital characters are determined by testing membership in 
> `CharacterSet.uppercaseLetters` and `CharacterSet.lowercaseLetters` (Unicode 
> General Categories Lu and Lt).
> /// The conversion to lower case uses `Locale.system`, also known as 
> the ICU "root" locale. This means the result is consistent regardless of the 
> current user's locale and language preferences.
> ///
> /// Converting from camel case to snake case:
> /// 1. Splits words at the boundary of lower-case to upper-case
> /// 2. Inserts `_` between words
> /// 3. Lowercases the entire string
> /// 4. Preserves starting and ending `_`.
> ///
> /// For example, `oneTwoThree` becomes `one_two_three`. 
> `_oneTwoThree_` becomes `_one_two_three_`.
> ///
> /// - Note: Using a key encoding strategy has a nominal 

Re: [swift-evolution] async void

[Adam Kemp via swift-evolution]

> On Nov 9, 2017, at 11:02 AM, Wallacy  wrote:
> 
> So for me, this:
> 
> func OnButtonClicked(_ sender:AnyObject) {
> let button = sender as! UIButton
> button.isEnabled = false
> beginAsync {
> await DoSomethingAsync()
> button.isEnabled = true
> }
> }
> 
> Does not make any sense... Because await will not block the thread we can 
> assume (like the exemple on proposal) that compiler will actually do the same 
> what we will do using GDC and pick everyone to until the context ends and 
> encapsulate as completion handle to the away call.

I don’t understand what you’re saying here. In terms of GCD the above code is 
basically equivalent to this:

func buttonClicked(_ sender:AnyObject) {
let button = sender as! UIButton
button.isEnabled = false
doSomethingAsync { // completion callback, assume it’s on the main queue
button.isEnabled = true
}
}

> And this one:
> 
> @IBAction func buttonDidClick(sender:AnyObject) {
>   beginAsync {
> let image = await processImageData()
> // Do the update on the main thread/queue since it owns imageView.
> mainQ.async {
>   imageView.image = image
> }
>   }
> }
> 
> 
> Does not make any sense too.
> 
> The only way to await to do not block the thread is make a early return like 
> beginAsync and encapsulate as completion handle the rest of the code. 

This is why “await” can only be used in a function that is marked as “async”. 
The “async” keyword tells the compiler that this function will be broken up 
into parts, and its return value will be produced asynchronously.

One thing that might be confusing is that in the examples using “beginAsync” 
the trailing closure is the async function. That’s not obvious because there’s 
no “async” keyword, but it’s there in the signature of the closure argument:

func beginAsync(_ body: () async throws -> Void) rethrows -> Void

I’m not sure how the proposed design handles type checking for async closures. 
Is async part of the type? Can I declare a local closure variable as async? 
What are the rules for conversion between async and non-async closures? Is it a 
warning or error to use a closure literal without an async keyword that is 
assigned to an async closure variable or passed as an async closure argument?

C# dodges all of these issues because async isn't part of the type system. 
Closures that don’t return anything can be declared async just like void 
functions, and code that uses void-returning closures doesn’t need to care 
whether the implementation is async or not.

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

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Jose Cheyo Jimenez via swift-evolution]

- 1 I agree with Kevin Ballard. 

I think that it would be appropriate to nudge the user to use map instead. 

We already nudge people to use let over var so I think is sensible to do the 
same for misuses of flatMap when map is sufficient.

Thanks!


> On Nov 8, 2017, at 10:43 AM, John McCall via swift-evolution 
>  wrote:
> 
> 
>> On Nov 8, 2017, at 1:20 PM, Kevin Ballard > > wrote:
>> 
>> On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote:
>>> 
 On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution 
 > wrote:
 
 On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote:
> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>  
> 
> 
> • What is your evaluation of the proposal?
 
 This proposal is going to cause an insane amount of code churn. The 
 proposal suggests this overload of flatMap is used "in certain 
 circumstances", but in my experience it's more like 99% of all flatMaps on 
 sequences are to deal with optionals, not to flatten nested sequences.
 
> • Is the problem being addressed significant enough to warrant a change 
> to Swift?
 
 I don't think so. It's a fairly minor issue, one that really only affects 
 new Swift programmers anyway rather than all users, and it will cause far 
 too much code churn to be worthwhile.
 
 I'd much rather see a proposal to add a new @available type, something 
 like 'warning', that lets you attach an arbitrary warning message to a 
 call (which you can kind of do with 'deprecated' except that makes the 
 warning message claim the API is deprecated).
>>> 
>>> As review manager, I generally try to avoid commenting on threads, but I 
>>> find this point interesting in a way that, if you don't mind, I'd like to 
>>> explore.
>>> 
>>> Would this attribute not be a form of deprecation?  Certainly it acts to 
>>> discourage current and subsequent use, since every such use will evoke a 
>>> warning.
>>> 
>>> Is the word "deprecation" just too strong?  Often we think of deprecated 
>>> APIs as being ones with more functional problems, like an inability to 
>>> report errors, or semantics that must have seemed like a good idea at the 
>>> time.  Here it's just that the API has a name we don't like, and perhaps 
>>> "deprecation" feels unnecessarily judgmental.
>> 
>> What I'm suggesting is that we don't change the API name at all. That's why 
>> I don't want to use 'deprecated', because we're not actually deprecating 
>> something. I'm just suggesting an alternative way of flagging cases where 
>> the user tries to use flatMap but accidentally invokes optional hoisting, 
>> and that's by making a new overload of flatMap that works for non-optional 
>> (non-sequence) values and warns the user that what they're doing is better 
>> done as a map. Using the 'deprecated' attribute for this would be confusing 
>> because it would make it sound like flatMap itself is deprecated when it's 
>> not.
> 
> I see.  Thanks.
> 
> John.
> 
>> 
>>> Also, more practically, it conflates a relatively unimportant suggestion — 
>>> that we should call the new method in order to make our code clearer — with 
>>> a more serious one — that we should revise our code to stop using a 
>>> problematic API.  Yes, the rename has a fix-it, but still: to the extent 
>>> that these things demand limited attention from the programmer, that 
>>> attention should clearly be focused on the latter set of problems.  Perhaps 
>>> that sense of severity is something that an IDE should take into 
>>> consideration when reporting problems.
>>> 
>>> What else would you have in mind for this warning?
>> 
>> The main use for this warning would be for adding overloads to methods that 
>> take optionals in order to catch the cases where people invoke optional 
>> hoisting, so we can tell them that there's a better way to handle it if they 
>> don't have an optional. flatMap vs map is the obvious example, but I'm sure 
>> there are other cases where we can do this too.
>> 
>> But there are also other once-off uses. For example, in the past I've 
>> written a function that should only ever be used for debugging, so I marked 
>> it as deprecated with a message saying 'remove this before committing your 
>> code'. This warning would have been better done using the new 'warning' 
>> attribute instead of as a deprecation notice.
>> 
>> -Kevin Ballard
>> 
>>> John.
>>> 
 With that sort of thing we could then declare
 
 extension Sequence {
 @available(*, warning: "Use map instead")
 func flatMap(_ f: (Element) -> U) -> [U] {
 return map(f)
 }
 }
 
 And now if someone writes flatMap in 

Re: [swift-evolution] SE-0187: Introduce Sequence.filterMap(_:)

[Ben Cohen via swift-evolution]

> On Nov 9, 2017, at 11:43 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> let a : [Int?] = [1,2,3,nil,4,nil,5]
> 
> let b = a.flatMap { $0.flatMap{$0*10} }  // current

At the risk of taking us further down the rabbit hole…

You really want:

  let b = a.flatMap { $0.map{$0*10} }  // current

here. That is, a’s Element is Int?, and you want to apply Int->Int ($0*10) 
within the Int?, which is done with Optional.map(_:(Wrapped)->U)->U?

Optional.flatMap(_:(Wrapped)->U?) -> U? is for when you want to apply a 
function that returns an optional, but want to avoid “double-wrapping". So for 
example, you have a [String?], and you want to turn it into [Int] dropping any 
strings that are either nil or not an integer, you’d write:

  ["1","2",nil].flatMap { $0.flatMap(Int.init) } 

Which would return an [Int] of [1,2].

Optional.flatMap has the same “it happens to work with non-optional-returning 
functions” behavior as Collection.flatMap. But, though strange, it doesn’t 
cause the same level of active harm as Collection.flatMap. because we don’t 
implicitly convert elements to collections of elements.


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

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Ben Cohen via swift-evolution]

> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution 
>  wrote:
> 
> On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution 
> > wrote:
>> 
>> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:
>>> The problem in the Doodads example is that the name flatMap is used to 
>>> identify two distinct intents: concatenating arrays and filtering nils. One 
>>> can argue that those two operations are, in some lofty abstract sense, if 
>>> you squint, two instances of some more general pattern — but I don’t think 
>>> it’s fair to say that they represent the same intent. These separate 
>>> intents deserve separate names.
>> 
>> They absolutely represent the same intent if you think of an optional as a 
>> collection of zero or one elements.
>> 
>> -Kevin Ballard
> 
> But as `Optional` does not conform to collection, I would suggest that the 
> vast majority of of developers do _not_ think of them as a collection of zero 
> or one elements. (I certainly don’t know any who naturally think of it that 
> way.) We don’t treat Optional as a collection anywhere else in the API, and 
> it seems odd to do so in just this one case.
> 

And, to be clear, the lack of Collection conformance by Optional is an active 
choice, not an omission.

The “think of optionals as collections” explanation is a good way to help 
people who are confused by the overload. But an even better way would be to not 
have a confusing overload in the first place.

> -BJ
> ___
> 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] SE-0187: Introduce Sequence.filterMap(_:)

[Vladimir.S via swift-evolution]

On 09.11.2017 19:41, BJ Homer via swift-evolution wrote:




On Nov 9, 2017, at 9:37 AM, Sam Warner via swift-evolution 
 wrote:

I accept the motivation for this change, although I would mention that:
- in 2.5 years on a ~200k lines of Swift project
- we've seen a plenty of instances of `flatMap` used where `map` would have 
been sufficient, but
- we've never burned time on tracking down the sort of compiler issue described 
by the author in the Motivation. As I say, the argument is fair, but I am 
questioning how frequently this problem occurs.

I can't speak to the previous attempts to solve this problem, but I'd add my 
voice to anyone advocating solving this by having a compiler warning when 
`flatMap` is used redundantly(?).

If this proposal were to be accepted, I'd also question the choice of 
`filterMap` as a name. This name is presumably shorthand for 
`filterNonesAndMap`, which conveniently ignores the following:
- `flatMap` may be used on a sequence-of-sequences to flatten our to a 
single-dimensional sequence.
- `flatMap` may be used on other 'box' types, e.g. on an optional: 
`Optional("foo").flatMap { .some($0 + "bar") }` or on the common 
`Result` type.

Any re-naming of one `flatMap` should take these other uses into account, as 
they share conceptual details.

Thanks,

Sam


This proposal only proposes renaming the “filterNonesAndMap” variant (though 
that name is misleading, it would be “filterNonesAfterMapping” if anything); 
the other uses of flatMap will remain unchanged.


I wonder, if it's also about unwrapping optionals (not just about filtering nils out; so correct name seems like 
mapOptionalsThenSkipNilsAndUnwrap), why not unwrapMap, optionalMap or maybe flatOptionalMap or even flatUnwrapMap, or 
mapUnwrapped? Such name IMO will be more clear about what is the purpose, because personally for me 'filterMap' is very 
general name, something about filtering and map, nothing about optional/unwrapping/nils. I even think 'flatMap' has a 
better mental model(we have optionals .some and nils in array, and will have an array of unwrapped(flat) values without 
nils).


For comparision:

let a : [Int?] = [1,2,3,nil,4,nil,5]

let b = a.flatMap { $0.flatMap{$0*10} }  // current

let b = a.filterMap { $0.filterMap {$0*10} }  // suggested

let b = a.unwrapMap { $0.unwrapMap {$0*10} }  // alternative

let b = a.optionalMap { $0.optionalMap {$0*10} }  // alternative

print(b) // [10, 20, 30, 40, 50]



Vladimir.



-BJ
___
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] update on forum

[Jonathan Hull via swift-evolution]

Glad to see there is progress on this :-)

I am hoping, in addition to sections equivalent to the lists, there are areas 
for working groups on specific topics, and areas for 3rd party 
frameworks/packages to coordinate/cross-polinate ideas.  For example, I have 
code which I use as a more powerful (and easier to use) form of “bindings” 
which I am considering cleaning up and open sourcing. It would be nice to have 
a place on the forums where I could ask if others were interested in helping 
with that effort (or even just had advice for it). None of the lists seem to be 
right for that right now...

Thanks,
Jon 

> On Nov 9, 2017, at 6:13 AM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The decision to move to a forum was announced a while ago, and it hasn’t 
> appeared yet.  I think we will be making the move soon and I wanted to 
> provide some reasons why it was delayed and what comes next.
> 
> The reasons it was delayed are twofold:
> 
> -  When we (the community) decided to move to a forum there was plenty of 
> other planned infrastructure work that was in the works that took immediate 
> priority (such as the source compatibility suite and supporting Swift 4 
> development).
> 
> - In August (when Swift 4 was wrapping up) my team at Apple seriously picked 
> up the topic of the forum again and started looking in how to make it happen. 
>  At that point, a bunch of unexpected delays, one after the other, happened.  
> I can’t share these details (they are mostly non-technical) and going through 
> them would come off as me making a bunch of excuses anyway.  I do realize the 
> forum has been promised and not yet delivered for some time, and I know how 
> frustrating that is to the community.
> 
> Here’s what happens next:
> 
> - We plan on having the company behind Discourse.org  
> host the forums.  We’re wrapping up the remaining steps to issue a PO, but my 
> hope is to get that all done within the next couple weeks.  Thanksgiving in 
> the USA may delay that to the beginning of December.
> 
> - My understanding is the forum will still have a swift.org 
>  address, so the hosting is just an implementation detail.
> 
> - The company hosting Discourse.org  will migrate the 
> existing mailing list archives over to the new forum.  One thing we will need 
> to figure out (possibly as a community?) are specific requirements we have in 
> place for that migration.  The new forums don’t have to exactly mirror how 
> the mailing lists are structured today, and part of the reason to move to the 
> forum was motivated by having new opportunities to structure conversations.
> 
> I suspect there will be some trial and error with moving over the existing 
> mailing lists to the new forum, and I don’t have a good feel on how long that 
> will take.  However, once we reach that stage, it should be very transparent 
> to the community what exactly is going on.  My hope is that process will 
> start in December.
> 
> Ted
> ___
> 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] async void

[Wallacy via swift-evolution]

Before i make a comment on this topic i need to confirm something:

On original proposal, this:

func processImageData1(completionBlock: (result: Image) -> Void) {
loadWebResource("dataprofile.txt") { dataResource in
loadWebResource("imagedata.dat") { imageResource in
decodeImage(dataResource, imageResource) { imageTmp in
dewarpAndCleanupImage(imageTmp) { imageResult in
completionBlock(imageResult)
}
}
}
}
}


Is converted to this:

func processImageData1() async -> Image {
let dataResource  = await loadWebResource("dataprofile.txt")
let imageResource = await loadWebResource("imagedata.dat")
let imageTmp  = await decodeImage(dataResource, imageResource)
let imageResult   = await dewarpAndCleanupImage(imageTmp)
return imageResult
}



And has other sentences explain that await will not block the thread etc...

So for me, this:

func OnButtonClicked(_ sender:AnyObject) {

let button = sender as! UIButton
button.isEnabled = false
beginAsync {
await DoSomethingAsync()
button.isEnabled = true
}
}


Does not make any sense... Because await will not block the thread we can
assume (like the exemple on proposal) that compiler will actually do the
same what we will do using GDC and pick everyone to until the context ends
and encapsulate as completion handle to the away call.

So we will only have this:

func OnButtonClicked(_ sender:AnyObject) {

let button = sender as! UIButton

button.isEnabled = false

await DoSomethingAsync()

button.isEnabled = true

}


I don't know how to handle reentrante or something like that, but  the
proposal give me the impression this behavior.

In the other way, await will block the thread!

I know the proposal give us this exemple:

@IBAction func buttonDidClick(sender:AnyObject) {
  // 1  beginAsync {
// 2let image = await processImage()
imageView.image = image
  }
  // 3}



But this is different, because "3" will be fired before "2".

And this one:

@IBAction func buttonDidClick(sender:AnyObject) {
  beginAsync {
let image = await processImageData()
// Do the update on the main thread/queue since it owns imageView.
   mainQ.async {
  imageView.image = image
}
  }
}



Does not make any sense too.

The only way to await to do not block the thread is make a early return
like beginAsync and encapsulate as completion handle the rest of the code.

If not, i don't see how the first exemple of the proposal will be made.

Em qua, 8 de nov de 2017 às 15:55, Adam Kemp via swift-evolution <
swift-evolution@swift.org> escreveu:

> (I changed the subject since it’s not really the same topic)
>
> The short answer is that this code has the same problem even without async
> void:
>
> func sendMessage() {
> beginAsync {
> // …
> }
> }
>
> func onButtonClick() {
> sendMessage()
> showAlert("message sent")
> }
>
>
> If you want someone to be able to wait for something to finish then you
> make your function awaitable. So what does that mean for an async function
> that doesn’t really return anything? To understand what I’m thinking it
> helps to understand how C# does it, since that’s the model I’m proposing,
> and I think it works really well. In C# it works like this:
>
> void NoReturn() { }
> int IntReturn() { return 0; }
>
> async Task NoReturnAsync() { await Task.Yield(); }
> async Task IntReturnAsync() { await Task.Yield(); return 0; }
>
> async void NoReturnAsyncVoid() { await Task.Yield(); }
>
> async Task Caller()
> {
> NoReturn();
> int i = IntReturn();
> await NoReturnAsync();
> int j = await IntReturnAsync();
>
> NoReturnAsync(); // this cannot be awaited
> }
>
>
> An important difference is that in C# the async keyword does not make a
> function awaitable. Notice how NoReturnAsyncVoid is marked as “async”, but
> the caller cannot use “await” with it. So what do you do if you want to
> wait for it to finish, like in your example? Well notice that another
> function NoReturnAsync doesn’t actually appear to return anything, even
> though its return type is Task. The compiler transforms the function into
> pieces where the first piece (the one actually called by the caller)
> returns a Task object. A bare Task is only used for waiting for completion,
> whereas a Task also holds a return value. When you make a function that
> returns T async then you change the return type to Task. When you make a
> void function async and want to allow the caller to wait for it to finish
> then you change the void to Task. When you make a void function async but
> want the caller to not wait for it to finish then you leave it as void.
>
> This is subtle, but consider this alternative form:
>
> void NoReturn() { }
> int IntReturn() { return 0; }
>
> Task NoReturnAsync() { return Task.Yield(); }
> Task IntReturnAsync() { return Task.Yield(); return 0; }
>
> 

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Tino Heth via swift-evolution]

> The problem in the Doodads example is that the name flatMap is used to 
> identify two distinct intents: concatenating arrays and filtering nils.
You may have read about my issues with the prefix, but following the same logic 
of „filtering nils“, the other variant of flatMap just filters out empty arrays.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[BJ Homer via swift-evolution]

On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution 
 wrote:
> 
> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:
>> The problem in the Doodads example is that the name flatMap is used to 
>> identify two distinct intents: concatenating arrays and filtering nils. One 
>> can argue that those two operations are, in some lofty abstract sense, if 
>> you squint, two instances of some more general pattern — but I don’t think 
>> it’s fair to say that they represent the same intent. These separate intents 
>> deserve separate names.
> 
> They absolutely represent the same intent if you think of an optional as a 
> collection of zero or one elements.
> 
> -Kevin Ballard

But as `Optional` does not conform to collection, I would suggest that the vast 
majority of of developers do _not_ think of them as a collection of zero or one 
elements. (I certainly don’t know any who naturally think of it that way.) We 
don’t treat Optional as a collection anywhere else in the API, and it seems odd 
to do so in just this one case.

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

Re: [swift-evolution] SE-0187: Introduce Sequence.filterMap(_:)

[BJ Homer via swift-evolution]

> 
> On Nov 9, 2017, at 11:35 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> This proposal only proposes renaming the “filterNonesAndMap” variant (though 
>> that name is misleading, it would be “filterNonesAfterMapping” if anything); 
>> the other uses of flatMap will remain unchanged.
> … then it should be really right: As I learned in the thread, there is a map 
> step before filter, and another map afterwards - so 
> „filterNonesAfterMappingAndMap“ (that’s why I don’t like the use of the term 
> „filter“ here — if you want an accurate name that contains this verb, it gets 
> quite complicated…)
 
But obviously “filterNonesAfterMappingAndMap” is not a name we’re going to end 
up with. You can argue that “filterMap” is not completely faithful to the 
internal implementation, but I think it’s clearly better than “flatMap” in this 
case, which is even more incorrect. I’m not opposed to finding a better name 
than “filterMap”, but so far I haven’t seen one.

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

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Wallacy via swift-evolution]

Em qui, 9 de nov de 2017 às 03:42, Ted Kremenek 
escreveu:

> These are some really interesting analogies.  How would you imagine the
> community “governance” of these “plugins” (which I assume would be
> libraries or packages) to be managed?
>

Pretty much like a TV/Games/etc community forums. The owner (In this case
Apple/Core Team) invite some people to help (Moderators etc) to maintain
the main project, look if everyone is follow the rules, etc.

Also is similar as other opensource projects.


> What does it mean for the “full community” to manage them, and provide the
> rough guarantees you suggest?
>

NPM has thousands of projects, is impossible to check all of then. And
besides be a good reference, here we have the opportunity do to something
better... Because...Because...Because I believe we can ;)

So what i expect?

Lets make some assumptions here, just to play a little:

Let assume we build a Indexer like IBM Swift Package Catalog (
https://packagecatalog.com/ ) over Swift.org.

And like Swift Source Compatibility Suite to be "indexed" the author of the
project needs to send the request to be accepted.

Lets assume the same rules as Compatibility Suite:
Acceptance Criteria

To be accepted into the Swift source compatibility test suite, a project
must:

   1. Target Linux, macOS, or iOS/tvOS/watchOS device
   2. Be an *Xcode* or *Swift Package Manager* project (Carthage and
   CocoaPods are currently unsupported but are being explored to be supported
   in the future)
   3. Support building on either Linux or macOS
   4. Be contained in a publicly accessible git repository
   5. Maintain a project branch that builds against Swift 3.0 compatibility
   mode and passes any unit tests
   6. Have maintainers who will commit to resolve issues in a timely manner
   7. Be compatible with the latest GM/Beta versions of *Xcode* and
   *swiftpm*
   8. Add value not already included in the suite
   9. Be licensed with one of the following permissive licenses:
  - BSD
  - MIT
  - Apache License, version 2.0
  - Eclipse Public License
  - Mozilla Public License (MPL) 1.1
  - MPL 2.0
  - CDDL


And lets assume like GStreamer we have 4 categories of projects.

Base; Good; Bad; Unsupported. (just as exemple)

*swift-extension-base *
a small and fixed set of features, covering a small range of possible types
of elements; these are continuously kept up-to-date with any core changes
during the development series.

   - We believe distributors can safely ship these features
   - People writing elements should base their code on these elements
   - These elements come with examples, documentation, and regression tests


*swift-extension-good *a set of features that we consider to have good
quality code, correct functionality, our preferred license (Swift Licence),
and covering a wide range features.

   - We believe distributors can safely ship these plug-ins
   - People writing elements should base their code on these elements

*swift-extension-bad *
a set of features that have good quality and correct functionality, but
distributing them might pose problems. The license on either the or the
supporting libraries might not be how we'd like. The code might be widely
known to present patent problems.

   - Distributors should check if they want/can ship these plug-ins
   - People writing elements should base their code on these elements

*swift-extension-unsupported  *
a set of features that aren't up to par compared to the rest. They might be
close to being good quality, but they're missing something - be it a good
code review, some documentation, a set of tests, a real live maintainer, or
some actual wide use.

   - If the features break, you can't complain - instead, you can fix the
   problem and send us a patch, or bribe someone into fixing them for you
   - New contributors can start here for things to work on


After request to be accepted is made, let's assume some area using forums
or similar to make that request happen, the project will be classified in
one of those categories, and will have people to look if projects accepted
on "base"/"good"/"bad" have the minimum requirements to keep on those
categories. Unsupported can be used for projects are not maintained any
more, or does not follow all rules, but at least one of then.

How?

At base/good level wee need only a few projects? 10-100? I don't know, but
a sane number to according to the number of people who are available to
monitor them, a project on this level may even have no commit for a while.
At "bad" level we can have much more projects and only rely to automatic
checks like, number of downloads, starts, comments, commits etc to see if
this project is maintened (packagecatalog give us a few metrics too). If
the project owner believes that your project is relevant enough to be
considered "good" needs to make a request.

In this cenário, you can have your project automatically downgraded to
unsupported 

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Kevin Ballard via swift-evolution]

On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:> The 
problem in the Doodads example is that *the name flatMap is used
> to identify two distinct intents*: concatenating arrays and filtering
> nils. One can argue that those two operations are, in some lofty
> abstract sense, if you squint, two instances of some more general
> pattern — but I don’t think it’s fair to say that they represent the
> same *intent*. These separate intents deserve separate names.
They absolutely represent the same intent if you think of an optional as
a collection of zero or one elements.
-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0187: Introduce Sequence.filterMap(_:)

[Tino Heth via swift-evolution]

> This proposal only proposes renaming the “filterNonesAndMap” variant (though 
> that name is misleading, it would be “filterNonesAfterMapping” if anything); 
> the other uses of flatMap will remain unchanged.
… then it should be really right: As I learned in the thread, there is a map 
step before filter, and another map afterwards - so 
„filterNonesAfterMappingAndMap“ (that’s why I don’t like the use of the term 
„filter“ here — if you want an accurate name that contains this verb, it gets 
quite complicated…)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] async void

[Nobuo Saito via swift-evolution]

Hi,
I have two opinion about async void function,

1. I think async(or sync) function should has a returning value even if
type is void.
```
let result = await somethingAsyncVoid()
```
In this case the `result` will available when `someThingAsyncVoid` was
completed.
Someone can omit it, but it should be usable for other one who want to use
it.
Even if someone omit returning value in async void function, the function
should return result(void) when process was finished.


2. About async throws function.
We should consider about combine `async` and `throws` function. Some
failure may happen asynchronously, we cannot solve the `async error` if we
ignore await async void function.

2017-11-09 2:55 GMT+09:00 Adam Kemp via swift-evolution <
swift-evolution@swift.org>:

> (I changed the subject since it’s not really the same topic)
>
> The short answer is that this code has the same problem even without async
> void:
>
> func sendMessage() {
> beginAsync {
> // …
> }
> }
>
> func onButtonClick() {
> sendMessage()
> showAlert("message sent")
> }
>
>
> If you want someone to be able to wait for something to finish then you
> make your function awaitable. So what does that mean for an async function
> that doesn’t really return anything? To understand what I’m thinking it
> helps to understand how C# does it, since that’s the model I’m proposing,
> and I think it works really well. In C# it works like this:
>
> void NoReturn() { }
> int IntReturn() { return 0; }
>
> async Task NoReturnAsync() { await Task.Yield(); }
> async Task IntReturnAsync() { await Task.Yield(); return 0; }
>
> async void NoReturnAsyncVoid() { await Task.Yield(); }
>
> async Task Caller()
> {
> NoReturn();
> int i = IntReturn();
> await NoReturnAsync();
> int j = await IntReturnAsync();
>
> NoReturnAsync(); // this cannot be awaited
> }
>
>
> An important difference is that in C# the async keyword does not make a
> function awaitable. Notice how NoReturnAsyncVoid is marked as “async”, but
> the caller cannot use “await” with it. So what do you do if you want to
> wait for it to finish, like in your example? Well notice that another
> function NoReturnAsync doesn’t actually appear to return anything, even
> though its return type is Task. The compiler transforms the function into
> pieces where the first piece (the one actually called by the caller)
> returns a Task object. A bare Task is only used for waiting for completion,
> whereas a Task also holds a return value. When you make a function that
> returns T async then you change the return type to Task. When you make a
> void function async and want to allow the caller to wait for it to finish
> then you change the void to Task. When you make a void function async but
> want the caller to not wait for it to finish then you leave it as void.
>
> This is subtle, but consider this alternative form:
>
> void NoReturn() { }
> int IntReturn() { return 0; }
>
> Task NoReturnAsync() { return Task.Yield(); }
> Task IntReturnAsync() { return Task.Yield(); return 0; }
>
> void NoReturnAsyncVoid() { Task.Yield(); }
>
> async Task Caller()
> {
> NoReturn();
> int i = IntReturn();
> await NoReturnAsync();
> int j = await IntReturnAsync();
>
> NoReturnAsync(); // this cannot be awaited
> }
>
>
> I changed all of the “async" functions above except for Caller by removing
> the “async” keyword and (where applicable) added return statements. Now
> none of those functions is async, but they are functionally equivalent.
> Notice that the async Caller (which I didn’t change at all) can still await
> the ones that return Task or Task. That’s because, again, in C# the
> async keyword does not mean “this can be awaited”. Being able to await a
> function call is orthogonal to whether that function is marked as async.
>
> Async means only one thing: that function can use the await keyword, and
> it will be decomposed by the compiler accordingly. So what can you await?
> Anything that’s “awaitable”. :) Basically if the return type of the
> function has a GetAwaiter method that returns a type that has a few
> properties and methods then you can use await on that function. This is
> described here:  com/pfxteam/2011/01/13/await-anything/>. Task happens to have a
> GetAwaiter ( threading.tasks.task.getawaiter(v=vs.110).aspx>) method that returns a
> TaskAwaiter ( compilerservices.taskawaiter(v=vs.110).aspx>), which happens to have an
> IsCompleted property and GetResult and OnCompleted methods.
>
> You can make any type awaitable by supplying a suitable GetAwaiter
> implementation, even using an extension method. I think this could probably
> be done with protocols and extensions in Swift.
>
> Back to the problem you described: wouldn’t an async void method be
> confusing to callers who expect it to finish before returning? 

Re: [swift-evolution] JSONEncoder: Key strategies

[Itai Ferber via swift-evolution]

Hi Brent,

Perhaps the wording would be better phrased as "boundary from 
non-uppercase-character to uppercase-character", i.e. numbers and Emoji 
are treated the same as lowercase characters and are included in the 
original word.
The following are [unit test cases from the associated 
PR](https://github.com/apple/swift/pull/12779/files#diff-26b09c16508c21f9f59dcf6c7a41d4b4R422), 
which should indicate the behavior implemented here:


```swift
let toSnakeCaseTests = [
  ("simpleOneTwo", "simple_one_two"),
  ("myURL", "my_url"),
  ("singleCharacterAtEndX", "single_character_at_end_x"),
  ("thisIsAnXMLProperty", "this_is_an_xml_property"),
  ("single", "single"), // no underscore
  ("", ""), // don't die on empty string
  ("a", "a"), // single character
  ("aA", "a_a"), // two characters
  ("version4Thing", "version4_thing"), // numerics
  ("partCAPS", "part_caps"), // only insert underscore before first all 
caps
  ("partCAPSLowerAGAIN", "part_caps_lower_again"), // switch back and 
forth caps.
  ("manyWordsInThisThing", "many_words_in_this_thing"), // simple 
lowercase underscore more

  ("asdfĆqer", "asdf_ćqer"),
  ("already_snake_case", "already_snake_case"),
  ("dataPoint22", "data_point22"),
  ("dataPoint22Word", "data_point22_word"),
  ("_oneTwoThree", "_one_two_three"),
  ("oneTwoThree_", "one_two_three_"),
  ("__oneTwoThree", "__one_two_three"),
  ("oneTwoThree__", "one_two_three__"),
  ("_oneTwoThree_", "_one_two_three_"),
  ("__oneTwoThree", "__one_two_three"),
  ("__oneTwoThree__", "__one_two_three__"),
  ("_test", "_test"),
  ("_test_", "_test_"),
  ("__test", "__test"),
  ("test__", "test__"),
  ("m͉̟̹y̦̳G͍͚͎̳r̤͉̤͕ͅea̲͕t͇̥̼͖U͇̝̠R͙̻̥͓̣L̥̖͎͓̪̫ͅR̩͖̩eq͈͓u̞e̱s̙t̤̺ͅ", 
"m͉̟̹y̦̳_g͍͚͎̳r̤͉̤͕ͅea̲͕t͇̥̼͖_u͇̝̠r͙̻̥͓̣l̥̖͎͓̪̫ͅ_r̩͖̩eq͈͓u̞e̱s̙t̤̺ͅ"), 
// because Itai wanted to test this

  ("", "") // fishy emoji example?
]
```

And for completeness, the [complementary test 
cases](https://github.com/apple/swift/pull/12779/files#diff-26b09c16508c21f9f59dcf6c7a41d4b4R540):


```swift
let fromSnakeCaseTests = [
  ("", ""), // don't die on empty string
  ("a", "a"), // single character
  ("ALLCAPS", "ALLCAPS"), // If no underscores, we leave the word as-is
  ("ALL_CAPS", "allCaps"), // Conversion from screaming snake case
  ("single", "single"), // do not capitalize anything with no 
underscore

  ("snake_case", "snakeCase"), // capitalize a character
  ("one_two_three", "oneTwoThree"), // more than one word
  ("one_2_three", "one2Three"), // numerics
  ("one2_three", "one2Three"), // numerics, part 2
  ("snake_Ćase", "snakeĆase"), // do not further modify a capitalized 
diacritic

  ("snake_ćase", "snakeĆase"), // capitalize a diacritic
  ("alreadyCamelCase", "alreadyCamelCase"), // do not modify already 
camel case

  ("__this_and_that", "__thisAndThat"),
  ("_this_and_that", "_thisAndThat"),
  ("this__and__that", "thisAndThat"),
  ("this_and_that__", "thisAndThat__"),
  ("this_aNd_that", "thisAndThat"),
  ("_one_two_three", "_oneTwoThree"),
  ("one_two_three_", "oneTwoThree_"),
  ("__one_two_three", "__oneTwoThree"),
  ("one_two_three__", "oneTwoThree__"),
  ("_one_two_three_", "_oneTwoThree_"),
  ("__one_two_three", "__oneTwoThree"),
  ("__one_two_three__", "__oneTwoThree__"),
  ("_test", "_test"),
  ("_test_", "_test_"),
  ("__test", "__test"),
  ("test__", "test__"),
  ("_", "_"),
  ("__", "__"),
  ("___", "___"),
  ("m͉̟̹y̦̳G͍͚͎̳r̤͉̤͕ͅea̲͕t͇̥̼͖U͇̝̠R͙̻̥͓̣L̥̖͎͓̪̫ͅR̩͖̩eq͈͓u̞e̱s̙t̤̺ͅ", 
"m͉̟̹y̦̳G͍͚͎̳r̤͉̤͕ͅea̲͕t͇̥̼͖U͇̝̠R͙̻̥͓̣L̥̖͎͓̪̫ͅR̩͖̩eq͈͓u̞e̱s̙t̤̺ͅ"), 
// because Itai wanted to test this

  ("_", "") // fishy emoji example?
]
```

— Itai

On 9 Nov 2017, at 5:57, Brent Royal-Gordon via swift-evolution wrote:

> On Nov 6, 2017, at 12:54 PM, Tony Parker via swift-evolution 
 wrote:


Converting from camel case to snake case:

1. Splits words at the boundary of lower-case to upper-case
2. Inserts `_` between words
3. Lowercases the entire string
4. Preserves starting and ending `_`.

For example, `oneTwoThree` becomes `one_two_three`. `_oneTwoThree_` 
becomes `_one_two_three_`.


My first thought was "are you handling `valueAsHTML` correctly?", but 
it looks like you are with the "boundary of lower-case to upper-case" 
wording. But what do you plan to do for numbers? Characters in 
caseless scripts? Emoji (which are valid in Swift identifiers)? I 
don't necessarily have strong opinions about the right answer—just 
want to make sure you do *something* about it.


--
Brent Royal-Gordon
Architechies




___
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] Remove AnyObject Constraint for Objective-C Lightweight Generics

[Philippe Hausler via swift-evolution]

I have personally filed a few bugs on this; and I definitely consider it a bug 
that we cannot store Any in generics for objc. There are however some problem 
areas that might be worth considering while fixing this bug. 

1) We need to ensure this does not cause source churn - I would expect swift 4 
to be source compatible with swift 5.

2) There are a few cases that might be a bit cagey - you claim NSCache, but 
would it be surprising that the boxed object having no refs gets purged? How 
bout NSPointerArray? 

3) Since Foundation is likely the most impact here I think it would be useful 
to audit the results of this before pushing it out; specifically the Foundation 
internal builds so that we can make sure the things we are working on function 
correctly.

Do you have implementations in the works yet? I really think this is important 
for us to get in (especially before the ABI gets locked down cause it could 
have impact there…)

> On Nov 8, 2017, at 11:49 AM, Riley Testut via swift-evolution 
>  wrote:
> 
> Hi Swift-Evolution,
> 
> Back when SE-0057 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md
>  
> )
>  was proposed, it included the following passage:
> 
> The generic type parameters in Swift will always be class-bound, i.e., the 
> generic class will have the requirement T : AnyObject.
> This made sense at the time, since Swift <-> Objective-C interoperability was 
> only possible with class types (AnyObject). However, several months after 
> SE-0057 was accepted, SE-0116 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md
>  
> )
>  was accepted, which allowed for bridging any type to Objective-C, not just 
> class types.
> 
> This greatly improved interoperability between Swift and Objective-C code, 
> but the AnyObject restriction on Objective-C generics remained. This issue is 
> especially apparent when using lesser-known Objective-C collection types such 
> as NSCache, where it may make sense to store value types or use value types 
> as the keys, but the compiler does not allow it.
> 
> I propose that this restriction is lifted, and that generic Objective-C 
> parameters are no longer restricted to conforming to AnyObject. I’m assuming 
> this is not as straightforward as it might seem at first to implement, but I 
> think the benefits would make the effort worth it, since this seems like an 
> overlooked case and not intentionally kept this way.
> 
> Thoughts?
> ___
> 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] SE-0187: Introduce Sequence.filterMap(_:)

[BJ Homer via swift-evolution]

> On Nov 9, 2017, at 9:37 AM, Sam Warner via swift-evolution 
>  wrote:
> 
> I accept the motivation for this change, although I would mention that:
> - in 2.5 years on a ~200k lines of Swift project
> - we've seen a plenty of instances of `flatMap` used where `map` would have 
> been sufficient, but
> - we've never burned time on tracking down the sort of compiler issue 
> described by the author in the Motivation. As I say, the argument is fair, 
> but I am questioning how frequently this problem occurs.
> 
> I can't speak to the previous attempts to solve this problem, but I'd add my 
> voice to anyone advocating solving this by having a compiler warning when 
> `flatMap` is used redundantly(?).
> 
> If this proposal were to be accepted, I'd also question the choice of 
> `filterMap` as a name. This name is presumably shorthand for 
> `filterNonesAndMap`, which conveniently ignores the following:
> - `flatMap` may be used on a sequence-of-sequences to flatten our to a 
> single-dimensional sequence.
> - `flatMap` may be used on other 'box' types, e.g. on an optional: 
> `Optional("foo").flatMap { .some($0 + "bar") }` or on the common 
> `Result` type.
> 
> Any re-naming of one `flatMap` should take these other uses into account, as 
> they share conceptual details.
> 
> Thanks,
> 
> Sam

This proposal only proposes renaming the “filterNonesAndMap” variant (though 
that name is misleading, it would be “filterNonesAfterMapping” if anything); 
the other uses of flatMap will remain unchanged.

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

[swift-evolution] SE-0187: Introduce Sequence.filterMap(_:)

[Sam Warner via swift-evolution]

I accept the motivation for this change, although I would mention that:
- in 2.5 years on a ~200k lines of Swift project
- we've seen a plenty of instances of `flatMap` used where `map` would have
been sufficient, but
- we've never burned time on tracking down the sort of compiler issue
described by the author in the Motivation. As I say, the argument is fair,
but I am questioning how frequently this problem occurs.

I can't speak to the previous attempts to solve this problem, but I'd add
my voice to anyone advocating solving this by having a compiler warning
when `flatMap` is used redundantly(?).

If this proposal were to be accepted, I'd also question the choice of
`filterMap` as a name. This name is presumably shorthand for
`filterNonesAndMap`, which conveniently ignores the following:
- `flatMap` may be used on a sequence-of-sequences to flatten our to a
single-dimensional sequence.
- `flatMap` may be used on other 'box' types, e.g. on an optional: `Optional
("foo").flatMap { .some($0 + "bar") }` or on the common `Result`
type.

Any re-naming of one `flatMap` should take these other uses into account,
as they share conceptual details.

Thanks,

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

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

[Chris Lattner via swift-evolution]

> On Nov 6, 2017, at 4:13 AM, Jon Shier  wrote:
> 
>   This consideration is further complicated by the possible addition of 
> typed throws in the future. However, the most commonly suggested 
> implementation fo typed throws keeps the ability for throws to be untyped. 
> Additionally, the feature usually allows multiple types to be thrown from a 
> single function. Result can handle all of these scenarios automatically, 
> since it reduces all errors down to Error. A Result however, would 
> either lose the ability to encapsulate any function with multiple error 
> types, or otherwise have to wrap those cases in something like AnyError, in 
> additional to having to do so in the untyped case. 

As I mentioned up-thread, this proposal isn’t going to go anywhere without a 
proper discussion of typed throws.  There are good reasons for two possible 
designs:

1. Never add typed throws.
2. Add the ability to specify a single type thrown (typically an enum, but 
could be a struct), which defaults to Error if unspecified.

I don’t see any reason to add an arbitrary *list* of thrown types.  Swift 
already has ways to specify alternatives (enums) and this would encourage 
exactly the behavior from APIs that we want to avoid.

This choice between 1/2 needs to be decided before introducing result, because 
#1 means it should be Result, and #2 means it should be Result. If this 
is important to you, I’d suggest starting a dedicated discussion thread about 
the topic.

-Chris


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

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[BJ Homer via swift-evolution]

On Nov 9, 2017, at 9:13 AM, Tino Heth via swift-evolution 
 wrote:
> 
> 
>> Experienced programmers (as experienced as any Swift programmer can be for a 
>> 4-year-old language) frequently use flatMap when they mean map
> When you look at those examples:
> What would stop those programmers to use filterMap in the exact same way, 
> instead of switching to map?
> A hypothetic migrator most likely would just replace names…


The migrator would already have to be aware of the return type of the closure 
(to avoid migrating cases where it’s actually returning a sequence as 
expected), so the migrator could easily only migrate the ones that are actually 
returning optionals in the first place.

Programmers could continue to use filterMap incorrectly, but it would be a more 
explicit choice. Currently, there’s a sense among some Swift users (including 
some that I know personally) that flatMap is the “smart” thing to use with 
collections because monads or something, without any real understanding of why 
that is. (Remember, Swift doesn’t even have a “flatten()” function anymore, so 
the name “flatMap" is far from obvious.) I think it’s less likely that people 
will continue to use “filterMap” when they know no filtering is happening.

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

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

[Jon Gilbert via swift-evolution]

To those who pointed out that XCode can already fold comment blocks, let me 
point out that only works in XCode, and not in, say, github. 

If my pitch were implemented, your IDE could still show you the documentation 
inline with the code. 

In fact, XCode already lets you option-click a function call to see a pop-up 
that contains the documentation (which currently comes from the doc comments 
but could easily come from a .swiftDoc file). XCode can also already show you 
the documentation in the help sidebar. 

So why not go a step further and have all documentation in a separate file, 
then have the IDE be able to make it appear as if it were inline, but without 
it affecting the line numbers of code?

As well, you could have PR rules that permit .swiftDoc-only commits with fewer 
required code reviewers. The IDE could require that any new .swift file to be 
accompanied by a .swiftDoc file. 

During code review, empty .swiftDoc commits, or commits that substantially 
change a .swift file without changing the associated .swiftDoc file, would 
stand out like a sore thumb during code review, helping to prevent 
documentation getting out of sync. 

As well, since the swiftDoc file could now be analyzed according to its own 
grammar, the compiler could even auto-generate the basic docs for any new 
function and throw warnings for any undocumented functions, arguments, vars, 
etc. 

The live Markdown capabilities already in XCode means that users could be 
prevented from incorrect Markdown by compiler errors/warnings. 

As well, when you’re browsing a repo in github, it would be trivial to open a 
second browser tab (or split view, thanks to the latest OSs) with the 
accompanying .swiftDoc markdown file (which github would auto-format, making it 
much more legible!). It’s easy to use command-f to jump to the declaration you 
are interested in, and XCode could of course jump you to it.

Currently there is nothing to prevent doc comments from getting out of sync 
with the code they are supposed to document, however with a .swiftDoc file I 
believe it would be easier for the compiler to make sure every function’s 
documentation at least has the correct labels for each argument, and include 
such changes into refactors.

This feature would be fully optional for folks who want to keep documentation 
in-line, or don’t have time to migrate existing projects. Of course, imagine if 
XCode could migrate your projects for you? :D

One last thing: using separate files for documentation would allow for comments 
to be in multiple languages. There are multiple ways this could be approached. 
One way would be for the .swiftDoc files that are in the same folder with your 
source to be in default language for the project (assuming English), and then 
the translated docs are kept in subfolders. Or, the translations could all just 
be in different parts of the same file, or they could all be kept in folders. 

I know project maintainers likely don’t want to think about “oh god the idea of 
maintaining multiple languages of documentation”, but some projects already 
have to do this, and for them, this might be a godsend, since the compiler 
would know if the files got out of sync. Also, it might be nice to refer to the 
docs in the native language of the project, when it’s not English, and the 
broken-English documentation makes no sense.

In the future (or even now), having docs in separate files could also make it 
much simpler to create an auto-translator, since the parts of a swiftDoc that 
refer to actual code could be in backticks, forcing monospace and preventing 
translation. m

In conclusion, I believe in the single responsibility principle. Making a 
.swift file contain two entirely different syntaxes of code (Swift and 
Markdown) seems like a violation of this. Having small comments and //MARK: -  
to help someone reading code is great, but huge paragraphs and lists of full 
documentation often requires more room than the code itself, so what am I 
looking at? Code or documentation? Both? It’s just bad design.

I’m just saying. :D

- Jon

> 
> On Nov 8, 2017, at 12:59, Rod Brown  wrote:
> 
> Hi Jon,
> 
> An interesting proposal. I see value in an external markdown-formatted 
> document to compliment our Swift code, but currently I already do this when 
> discussing ideas or architecture and just call it “.md”.
> 
> I agree with Erica on the point though that documentation with code is 
> actually helpful to me and I would probably prefer documentation around 
> methods and types to sit with the content itself. I also find documentation 
> really helpful in breaking up a swift file, away from being code soup, and 
> into a very formalised structure that I find easier to cognitively parse.
> 
> I really would like some work on Xcode though to allow hiding documentation, 
> and improvements to the generated interfaces which are somewhat lacking atm.
> 
> - Rod
>> 
>> On 9 Nov 2017, at 5:57 am, 

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

[Charles Srstka via swift-evolution]

> On Nov 8, 2017, at 10:51 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> I find more limiting the ability not to declare @objc a property of a class 
> that doesn't inherit from NSObject:
> 
> class Foo {
>   var x: Int = 0
> }
> 
> class Bar {
>   var foo = Foo() // Why shouldn't we allow this @objc? 
> }
> 
> or
> 
> protocol BarProtocol: AnyObject {
>   func fooDidBar(_ foo: Foo)
> }
> 
> class BarContoller: NSViewController {
>   @IBOutlet weak var delegate: BarProtocol? // Error - not expressible in 
> ObjC.
> }
> 
> While Foo doesn't inherit from NSObject, it still can have @objc members used 
> for binding. I have quite few classes that need to inherit from NSObject just 
> for that purpose.
> 
> I fully understand the logic behind it that it needs to be exported to ObjC 
> headers and runtime metadata, but I'd prefer these being exported as (id) 
> into ObjC rather than not allowing this at all as these are all objects that 
> can be passed into the ObjC world...

+1000. In addition to the issues raised above, this limitation wreaks havoc 
with my attempts to properly support KVO in Swift projects. You either have to 
create a second Any-typed property, bloating the interface, or you have to go 
with the old string-based key path API, which also locks you out of using the 
Swift 4 closure-based observers.

Charles

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

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Tino Heth via swift-evolution]

> Experienced programmers (as experienced as any Swift programmer can be for a 
> 4-year-old language) frequently use flatMap when they mean map
When you look at those examples:
What would stop those programmers to use filterMap in the exact same way, 
instead of switching to map?
A hypothetic migrator most likely would just replace names...___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

[Jon Gilbert via swift-evolution]

They removed the little UI sidebar that was so useful for code folding, though. 
I do hope it makes a return.

Also I am not saying projects should be forced to keep docs in separate files, 
just that it would be nice to have the option. I suppose it could be achieved 
through an XCode plugin though.

J

> On Nov 9, 2017, at 03:19, Ben Rimmington via swift-evolution 
>  wrote:
> 
> 
>> On 8 Nov 2017, at 18:57, Erica Sadun wrote:
>> 
>> Colocation of docs with the material they document is valuable to me and I 
>> presume anyone updating code. If anything, it would be nice if Xcode 
>> provided a show/hide doc headers toggle though.
> 
> [Xcode 9.1]
> 
> Editor > Code Folding > Fold Comment Blocks
> 
> Editor > Code Folding > Fold Methods & Functions
> ___
> 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] Large Proposal: Non-Standard Libraries

[Benjamin Spratling via swift-evolution]

Sound great!  

Last week I started working on a pure-swift graphics library, one goal being 
fast server-side graphics manipulations, and already have .png decode/encode, 
and quadratic bezier curve stroking implemented, slowly, and poorly.  I’m 
working on TrueType fonts right now, and intend to open it to other developers 
once the basic architecture is refined.  I intend to add SVG and JPEG support 
as well.  It seems like if there is a “swift-community blessed geometry 
library”, this would be a natural extension of that, or at least depend on it.

Much of this depends on compression support, which I’ve already published a 
first cut of at https://github.com/benspratling4/SwiftFoundationCompression .  
The goal there was a more “foundation” idea of compression than competing 
libraries, but it suffers from a lack of streaming support.

I would absolutely love a “BigNum” library.  Several encryption packages out 
there would benefit from it as well.  It seems arithmetic compression libraries 
would benefit, too.  Other useful Numeric types would include rational 
fractions, fixed-point, and short floats (Float16 is what Apple now thinks the 
future of images is, right?).  I’m happy to contribute; I end up writing those 
in a new language ever few years anyway.

-Ben Spratling


> On Nov 7, 2017, at 12:54 PM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Hi Swift-Evolution,
> ...
> 
> We propose to create an open-sourced "Non-Standard Library" effort that 
> coexists with, coordinates with, and is blessed by the open source Swift 
> development community. The "Non-Standard Library" will offer a well-curated, 
> high-value collection of routines, types, and documentation to support Swift 
> development on all platforms.
> …

> Suggested Libraries
> 
> There are several areas we think that are ripe for improvement and 
> implementation as a non-standard library, such as (but not limited to):
> A BigNum library
> A full-featured Random library
> A simplified date/time library
> A library for manipulating paths (that is not based on URL or String)
> An expanded Swift-native Geometry library and so forth.
> The scope and extent of the sublibraries would be proposed and debated on a 
> parallel Non-Standard Library Evolution development list.

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

Re: [swift-evolution] update on forum

[Ted Kremenek via swift-evolution]

I was thinking all the mailing lists.

> On Nov 9, 2017, at 7:07 AM, Alejandro Martinez  wrote:
> 
> Thanks for the clarification on that Ted :)
> Are all the mailing list gonna move there or only swift-evo?
> 
> On Thu, Nov 9, 2017 at 2:13 PM, Ted Kremenek via swift-evolution
>  wrote:
>> The decision to move to a forum was announced a while ago, and it hasn’t
>> appeared yet.  I think we will be making the move soon and I wanted to
>> provide some reasons why it was delayed and what comes next.
>> 
>> The reasons it was delayed are twofold:
>> 
>> -  When we (the community) decided to move to a forum there was plenty of
>> other planned infrastructure work that was in the works that took immediate
>> priority (such as the source compatibility suite and supporting Swift 4
>> development).
>> 
>> - In August (when Swift 4 was wrapping up) my team at Apple seriously picked
>> up the topic of the forum again and started looking in how to make it
>> happen.  At that point, a bunch of unexpected delays, one after the other,
>> happened.  I can’t share these details (they are mostly non-technical) and
>> going through them would come off as me making a bunch of excuses anyway.  I
>> do realize the forum has been promised and not yet delivered for some time,
>> and I know how frustrating that is to the community.
>> 
>> Here’s what happens next:
>> 
>> - We plan on having the company behind Discourse.org host the forums.  We’re
>> wrapping up the remaining steps to issue a PO, but my hope is to get that
>> all done within the next couple weeks.  Thanksgiving in the USA may delay
>> that to the beginning of December.
>> 
>> - My understanding is the forum will still have a swift.org address, so the
>> hosting is just an implementation detail.
>> 
>> - The company hosting Discourse.org will migrate the existing mailing list
>> archives over to the new forum.  One thing we will need to figure out
>> (possibly as a community?) are specific requirements we have in place for
>> that migration.  The new forums don’t have to exactly mirror how the mailing
>> lists are structured today, and part of the reason to move to the forum was
>> motivated by having new opportunities to structure conversations.
>> 
>> I suspect there will be some trial and error with moving over the existing
>> mailing lists to the new forum, and I don’t have a good feel on how long
>> that will take.  However, once we reach that stage, it should be very
>> transparent to the community what exactly is going on.  My hope is that
>> process will start in December.
>> 
>> Ted
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> 
> 
> -- 
> Alejandro Martinez
> http://alejandromp.com

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

Re: [swift-evolution] update on forum

[Alejandro Martinez via swift-evolution]

Thanks for the clarification on that Ted :)
Are all the mailing list gonna move there or only swift-evo?

On Thu, Nov 9, 2017 at 2:13 PM, Ted Kremenek via swift-evolution
 wrote:
> The decision to move to a forum was announced a while ago, and it hasn’t
> appeared yet.  I think we will be making the move soon and I wanted to
> provide some reasons why it was delayed and what comes next.
>
> The reasons it was delayed are twofold:
>
> -  When we (the community) decided to move to a forum there was plenty of
> other planned infrastructure work that was in the works that took immediate
> priority (such as the source compatibility suite and supporting Swift 4
> development).
>
> - In August (when Swift 4 was wrapping up) my team at Apple seriously picked
> up the topic of the forum again and started looking in how to make it
> happen.  At that point, a bunch of unexpected delays, one after the other,
> happened.  I can’t share these details (they are mostly non-technical) and
> going through them would come off as me making a bunch of excuses anyway.  I
> do realize the forum has been promised and not yet delivered for some time,
> and I know how frustrating that is to the community.
>
> Here’s what happens next:
>
> - We plan on having the company behind Discourse.org host the forums.  We’re
> wrapping up the remaining steps to issue a PO, but my hope is to get that
> all done within the next couple weeks.  Thanksgiving in the USA may delay
> that to the beginning of December.
>
> - My understanding is the forum will still have a swift.org address, so the
> hosting is just an implementation detail.
>
> - The company hosting Discourse.org will migrate the existing mailing list
> archives over to the new forum.  One thing we will need to figure out
> (possibly as a community?) are specific requirements we have in place for
> that migration.  The new forums don’t have to exactly mirror how the mailing
> lists are structured today, and part of the reason to move to the forum was
> motivated by having new opportunities to structure conversations.
>
> I suspect there will be some trial and error with moving over the existing
> mailing lists to the new forum, and I don’t have a good feel on how long
> that will take.  However, once we reach that stage, it should be very
> transparent to the community what exactly is going on.  My hope is that
> process will start in December.
>
> Ted
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Alejandro Martinez
http://alejandromp.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

> On Nov 8, 2017, at 11:49 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> 
>> On Nov 7, 2017, at 5:54 PM, Dave DeLong via swift-evolution 
>>  wrote:
>> 
>> Hi Swift-Evolution,
>> 
>> The Standard Library's goal is to be small and targeted. However, many 
>> aspects of Apple-provided frameworks need or offer opportunities for 
>> improvement or wholesale replacement. These enhancements lie beyond the 
>> scope of the Standard Library.
>> 
>> To address this, we'd like to propose the idea of a "Non-Standard Library"; 
>> this would be a library that ships with a regular installation of Swift, but 
>> is not imported into .swift files by the compiler, unless explicitly 
>> requested by the developer.
>> 
>> We are proposing a well-organized effort to parallel the Standard Library 
>> without putting additional implementation responsibilities onto the core 
>> team. This effort would mitigate what we see as platform-independent 
>> requirements that provide native Swift implementations that aren't burdened 
>> by Apple history.
> 
> Hi Dave,
> 
> As others have pointed out, we do already have a model for this sort of 
> thing: the swift server working group. 

Hi Chris,

While it is true we have the Swift server work group, it’s not clear that 
should be the default prototype model to follow here.

That work group was created with a specific purpose to help unify different 
efforts in the Swift on server community to establish a base set of 
fundamentals they all could rely upon.  But that was after there was already 
various library implementations/server frameworks in use that could be looked 
upon to inform technical decisions.  The work group is also a fairly 
heavyweight model; it is appropriate in many contexts but not all of them.

> 
> That said, there is another analogy which gets closer to what you’re asking 
> for: the Boost community for C++.  Boost was formed because the C++ committee 
> was too bogged down an wasn’t receptive to major library changes (at one 
> point in time).  Boost has effectively parallel leadership from the C++ 
> committee (though individuals are involved in both organizations of course).  
> This allows Boost to move faster, ship code, and get experience with it.
> 
> One of the specifically nice things about Boost is that they (at least 
> originally) focused on building out ideas, getting experience with them, and 
> then bringing the libraries back to the standard.  The libraries occasionally 
> undergo significant change when they are standardized, but the usage 
> experience is unmatchable, particularly for very large and complex APIs.

This “getting experiences with them” model is what appeals to me most about 
Boost, and is more-or-less what I was suggesting in my earlier reply on this 
thread as an important ingredient when considering how to extend “core Swift”.  
The Swift server work group in many ways already follows this model, as it is 
drawing from other technical work from efforts such as Kitura, Vapor, etc.

> 
> In the context of Swift, I think this sort of model could be very 
> interesting, because there are really several different independent things 
> going on: for a type like BigNum (for example) there are all the details of 
> the implementation and design on the one hand, but then there is also the 
> question of WHICH library it should ship with (Foundation or Swift or 
> something else). That second decision is much easier to make after the 
> community has converged on a specific design.
> 
> In any case, I think it would be a bad move for the official Swift 
> distributions to ship code that hasn’t been through the evolution process.  
> The idea of the Server working group is to delegate detailed design and 
> iteration to a team of experts, but then have them bring back the API to 
> evolution when the iteration is done and it is time to “standardize” it.  I 
> think that this is a good model.

The question in my mind is whether a “work group” is the right default model 
here.  It may be too heavyweight in many cases and perhaps not necessary for 
smaller efforts or efforts that involve less people.

Also, the server work group has a preconceived plan that the libraries are 
added to “core Swift”, or in some way become an official part of Swift.  I 
don’t think that needs to be an upfront goal for all Swift libraries out there. 
 The analogy for Boost is interesting; while Boost is a proving ground for many 
ideas that eventually make it back to the C++ standard, not all of those APIs 
have that fate and that seems fine too.

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

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Ted Kremenek via swift-evolution]

I have started a new thread.

> On Nov 9, 2017, at 2:05 AM, Adrian Zubarev  
> wrote:
> 
> Hello Ted, would you mind opening a new thread and post an update about the 
> forum and maybe answer a few minor questions like:
> - what is currently planned?
> - in which timeframe we *might* see the forum finally happening (don’t have 
> to be a promise)?
> - what happens to old mailing lists? (I’d say put a public archive somewhere, 
> maybe slightly better formatted than the mailing list is, but do not spam new 
> categories so that we can start with a fresh and clean forum. I also wouldn’t 
> bother with migrating old users to new accounts. If I’m interested in 
> contribution I can take a minute and create a new forum account. I mean we’re 
> not trying to sell here anything, so this shouldn’t be a high priority 
> right!?)
> 
> Thank you. :)
> 
> 
> Am 9. November 2017 um 07:12:10, Ted Kremenek via swift-evolution 
> (swift-evolution@swift.org) schrieb:
> 
>> 
>> 
>>> On Nov 8, 2017, at 12:08 PM, Kelvin Ma  wrote:
>>> 
>>> 
>>> 
 On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution 
  wrote:
 
 
> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> 
> 
>> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution 
>>  wrote:
>> 
>> I do not agree with Ted that only a few projects should be ranked, 
>> everyone, as it is in npm should be available. Only be graded according 
>> to recommendations.
>> 
> 
> I’m a bit confused.  I’m not sure what comments of mine I’m referring to.
 
 Clearly I’m double confused.  That meant to read “I’m not sure what 
 comments of mine *you* are referring to”.
 
 I fully support having a broad spectrum of libraries that the community 
 builds and uses.  Any library that we decide to make part of “core Swift” 
 — IMHO at a mature point in a library’s evolution — would need to have 
 high value to the majority of the community and would need to feel solid 
 enough that we can lock it in for both source and binary compatibility, 
 high quality of implementation with sustained maintenance, etc.
>>> 
>>> i mean I don’t think these approaches are incompatible. The “swift core” 
>>> could just make the process of independent libraries getting started 
>>> easier. Like right now there’s really no place to say “hey I just started a 
>>> library project for X, and anyone who wants to be involved should 
>>> contribute at Y github repo where it lives right now”. I’ve tried sending 
>>> that on this list before and it didn’t really work because mailing lists 
>>> aren’t really a good medium for that and no one wants the swift-evolution 
>>> list getting clogged with project-specific messages most people don’t care 
>>> about.
>>> 
>> 
>> 
>> These are great points.
>> 
>> FWIW, I’m getting optimistic about moving to a forum soon.  Would you expect 
>> that a forum could provide a better vehicle than a mailing list to arrange 
>> communication and interest within the community around building libraries?  
>> Not just doing shout outs for projects, but also doing possible API design 
>> review, etc.?
>> 
>> As an analogy, within Apple we have various mailing lists to review APIs, 
>> which is one mechanism used for different teams to co-review newly proposed 
>> APIs and consider how they compose together with other APIs.  It’s not 
>> always perfect, but it does help facilitate a culture of API review so that 
>> various APIs can be considered together and part of the same (or compatible) 
>> design philosophies.
>> 
>> One of the things that resonated to me from Dave DeLong’s proposal was a 
>> sense about having a set of libraries that are well-considered and their 
>> efforts coordinated.  While the coordination pitched in Dave’s proposal was 
>> about a focused effort on a particular set of libraries/features, 
>> coordination can also take the form of having a community that cares about 
>> building good APIs and can constructively discuss them.  This can be done 
>> while also completely factoring out whether or not those APIs are part of 
>> “core Swift”.  Further, shared API review wouldn’t necessarily be about 
>> making actual decisions — which is the case of swift-evolution when 
>> evaluating language and standard library changes — but offering advice.  
>> Fundamentally the library author still stays in control of their library and 
>> APIs, but the community could help in shaping up the gestalt of what are 
>> considered well-crafted Swift APIs in general.
>> 
>> Of course the big difference here with this idea compared to Apple’s 
>> internal API review process is that for Apple the APIs it vends are intended 
>> to be shipped together, and thus they must work together.  In open source, 
>> 

[swift-evolution] update on forum

[Ted Kremenek via swift-evolution]

The decision to move to a forum was announced a while ago, and it hasn’t 
appeared yet.  I think we will be making the move soon and I wanted to provide 
some reasons why it was delayed and what comes next.

The reasons it was delayed are twofold:

-  When we (the community) decided to move to a forum there was plenty of other 
planned infrastructure work that was in the works that took immediate priority 
(such as the source compatibility suite and supporting Swift 4 development).

- In August (when Swift 4 was wrapping up) my team at Apple seriously picked up 
the topic of the forum again and started looking in how to make it happen.  At 
that point, a bunch of unexpected delays, one after the other, happened.  I 
can’t share these details (they are mostly non-technical) and going through 
them would come off as me making a bunch of excuses anyway.  I do realize the 
forum has been promised and not yet delivered for some time, and I know how 
frustrating that is to the community.

Here’s what happens next:

- We plan on having the company behind Discourse.org  
host the forums.  We’re wrapping up the remaining steps to issue a PO, but my 
hope is to get that all done within the next couple weeks.  Thanksgiving in the 
USA may delay that to the beginning of December.

- My understanding is the forum will still have a swift.org  
address, so the hosting is just an implementation detail.

- The company hosting Discourse.org will migrate the existing mailing list 
archives over to the new forum.  One thing we will need to figure out (possibly 
as a community?) are specific requirements we have in place for that migration. 
 The new forums don’t have to exactly mirror how the mailing lists are 
structured today, and part of the reason to move to the forum was motivated by 
having new opportunities to structure conversations.

I suspect there will be some trial and error with moving over the existing 
mailing lists to the new forum, and I don’t have a good feel on how long that 
will take.  However, once we reach that stage, it should be very transparent to 
the community what exactly is going on.  My hope is that process will start in 
December.

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

Re: [swift-evolution] JSONEncoder: Key strategies

[Brent Royal-Gordon via swift-evolution]

> On Nov 6, 2017, at 12:54 PM, Tony Parker via swift-evolution 
>  wrote:
> 
> Converting from camel case to snake case:
> 
> 1. Splits words at the boundary of lower-case to upper-case
> 2. Inserts `_` between words
> 3. Lowercases the entire string
> 4. Preserves starting and ending `_`.
> 
> For example, `oneTwoThree` becomes `one_two_three`. `_oneTwoThree_` becomes 
> `_one_two_three_`.

My first thought was "are you handling `valueAsHTML` correctly?", but it looks 
like you are with the "boundary of lower-case to upper-case" wording. But what 
do you plan to do for numbers? Characters in caseless scripts? Emoji (which are 
valid in Swift identifiers)? I don't necessarily have strong opinions about the 
right answer—just want to make sure you do *something* about it.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Brent Royal-Gordon via swift-evolution]

> On Oct 31, 2017, at 9:31 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Since you bring it up, Python exceptions will be annoying - As with other 
> languages, Python can throw from an arbitrary expression.  Modeling 
> everything as throws in Swift would be super-annoying and unergonomic for the 
> programmer, because we'd require 'try' everywhere.  Thoughts on what to do 
> about that are welcome!


Add a `throws!` keyword to Swift, indicating that if a call is not covered by a 
`try` or `try?` keyword, a `try!` should be implicitly added.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-188 Make stdlib index types Hashable

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Nov 9, 2017, at 6:29 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Thu, Nov 9, 2017 at 05:28 Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> >   
>> > https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md
>> >
>> > • What is your evaluation of the proposal?
>> 
>> This all seems very sensible, but here's my big question:
>> 
>> AnyIndex, which type erases any index type at run-time, would not be 
>> hashable since it might wrap a non-hashable type.
>> 
>> Why not? Specifically, why shouldn't we require `Hashable` conformance on 
>> indices? Adding it would require changes to conforming types, sure, but 
>> indices are already required to be `Equatable`, and `Hashable` conformance 
>> just got really easy to add, and custom `Collection`s are a relatively rare 
>> and advanced feature.
> 
> For a source-breaking change, that’s the wrong question to ask. It’s not “why 
> not,” but “why so”? It’s so easy to add the conformance, and any type can opt 
> into it so easily, what is the gain by forcing it and can it be justified as 
> a source-breaking change?

In this case we’re talking about the requirements on indices when ABI stability 
happens.  That’s a pretty important point of design to get right.  I think 
Brent *is* asking the right question in this case.  I haven’t given it enough 
thought to form a clear opinion as to the answer yet.

> 
>> 
>> Is it worth a source break to add it? Personally, I think so—but even if you 
>> disagree, I think we should document why we decided not to add it.
>> 
>> > • Is the problem being addressed significant enough to warrant a change to 
>> > Swift?
>> 
>> Yes.
>> 
>> > • Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes.
>> 
>> > • If you have used other languages or libraries with a similar feature, 
>> > how do you feel that this proposal compares to those?
>> 
>> N/A.
>> 
>> > • How much effort did you put into your review? A glance, a quick reading, 
>> > or an in-depth study?
>> 
>> Quick reading, nothing more.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-188 Make stdlib index types Hashable

[Xiaodi Wu via swift-evolution]

On Thu, Nov 9, 2017 at 05:28 Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md
> >
> > • What is your evaluation of the proposal?
>
> This all seems very sensible, but here's my big question:
>
> AnyIndex, which type erases any index type at run-time, would not
> be hashable since it might wrap a non-hashable type.
>
> Why not? Specifically, why shouldn't we require `Hashable` conformance on
> indices? Adding it would require changes to conforming types, sure, but
> indices are already required to be `Equatable`, and `Hashable` conformance
> just got really easy to add, and custom `Collection`s are a relatively rare
> and advanced feature.


For a source-breaking change, that’s the wrong question to ask. It’s not
“why not,” but “why so”? It’s so easy to add the conformance, and any type
can opt into it so easily, what is the gain by forcing it and can it be
justified as a source-breaking change?


> Is it worth a source break to add it? Personally, I think so—but even if
> you disagree, I think we should document why we decided not to add it.
>
> > • Is the problem being addressed significant enough to warrant a change
> to Swift?
>
> Yes.
>
> > • Does this proposal fit well with the feel and direction of Swift?
>
> Yes.
>
> > • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
> N/A.
>
> > • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> Quick reading, nothing more.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Nov 9, 2017, at 3:16 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> I wish that the Swift-Evolution discussion around typed / untyped throws 
> would avoid three traps:
> 
> - a bloodshed between pro and anti typed-throws
> - a pro-typed-throws echo chamber (since untyped throws is the passive status 
> quo, and typed throws the energetic challenger)
> - even less average-joe-programmers than ever (on a topic that immensely 
> impacts their everyday job)
> 
> Shouldn't the community elect a benevolent dictator that would settle this 
> subject? The final choice has of course to be sensible, but also strong and 
> sharp.

This is different from the normal evolution process—especially now that we have 
an implementation requirement—but I think I'd like to see the pro-typed-throws 
side put together a proposal, and then we can bring it up for a review and 
decide whether we *eventually* (even if it's not important enough for Swift 5) 
want to have typed throws or not. People have been asking for this feature for 
years, nobody seems to think it has insurmountable technical obstacles, and 
it's now holding up other decisions, and yet it's never been a high enough 
priority for us to just make the decision. We should change that.

If it's rejected in review, we can design `Result` and everything else on the 
assumption that we'll never have it. If it's accepted, we'll know where the 
roadmap is going there, too. I might not even demand a detailed technical 
design—just a clear outline of what will and won't be possible (e.g. multiple 
error types or not?), some discussion of the use cases and drawbacks, and a 
chance to make a binding(-ish) decision on the question.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-188 Make stdlib index types Hashable

[Tino Heth via swift-evolution]

>   • What is your evaluation of the proposal?
„That’s not possible yet?“ ;-)

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?
Yes.
Conformance to Hashable might be useful in other areas besides key-paths, and 
even if not: The change shouldn’t do any harm

>   • Does this proposal fit well with the feel and direction of Swift?
I hope… it’s something that doesn’t increase language complexity, but rather 
simplifies by filling a gap.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-188 Make stdlib index types Hashable

[Brent Royal-Gordon via swift-evolution]

>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md
> 
> • What is your evaluation of the proposal?

This all seems very sensible, but here's my big question:

AnyIndex, which type erases any index type at run-time, would not be 
hashable since it might wrap a non-hashable type.

Why not? Specifically, why shouldn't we require `Hashable` conformance on 
indices? Adding it would require changes to conforming types, sure, but indices 
are already required to be `Equatable`, and `Hashable` conformance just got 
really easy to add, and custom `Collection`s are a relatively rare and advanced 
feature.

Is it worth a source break to add it? Personally, I think so—but even if you 
disagree, I think we should document why we decided not to add it.

> • Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes.

> • Does this proposal fit well with the feel and direction of Swift?

Yes.

> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?

N/A.

> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Quick reading, nothing more.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] .swiftDoc files instead of inline docs

[Ben Rimmington via swift-evolution]

> On 8 Nov 2017, at 18:57, Erica Sadun wrote:
> 
> Colocation of docs with the material they document is valuable to me and I 
> presume anyone updating code. If anything, it would be nice if Xcode provided 
> a show/hide doc headers toggle though.

[Xcode 9.1]

Editor > Code Folding > Fold Comment Blocks

Editor > Code Folding > Fold Methods & Functions
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gwendal Roué via swift-evolution]

> Le 9 nov. 2017 à 08:57, Chris Lattner via swift-evolution 
>  a écrit :
> 
> 
>> On Nov 6, 2017, at 4:13 AM, Jon Shier > > wrote:
>> 
>>  This consideration is further complicated by the possible addition of 
>> typed throws in the future. However, the most commonly suggested 
>> implementation fo typed throws keeps the ability for throws to be untyped. 
>> Additionally, the feature usually allows multiple types to be thrown from a 
>> single function. Result can handle all of these scenarios automatically, 
>> since it reduces all errors down to Error. A Result however, would 
>> either lose the ability to encapsulate any function with multiple error 
>> types, or otherwise have to wrap those cases in something like AnyError, in 
>> additional to having to do so in the untyped case. 
> 
> As I mentioned up-thread, this proposal isn’t going to go anywhere without a 
> proper discussion of typed throws.  There are two possible designs that have 
> strong rationale:
> 
> 1. Never add typed throws.
> 2. Add the ability to specify a single type thrown (typically an enum, but 
> could be a struct), which defaults to Error if unspecified.
> 
> In contrast, I don’t see any reason to add an arbitrary *list* of thrown 
> types, and I can’t imagine such a design happening.  Swift already has ways 
> to specify alternatives (enums) and this would encourage exactly the behavior 
> from APIs that we want to avoid.
> 
> This choice between 1/2 needs to be decided before introducing result, 
> because #1 means it should be Result, and #2 means it should be 
> Result. If this is important to you, I’d suggest starting a dedicated 
> discussion thread about the topic.

Hello,

I wish that the Swift-Evolution discussion around typed / untyped throws would 
avoid three traps:

- a bloodshed between pro and anti typed-throws
- a pro-typed-throws echo chamber (since untyped throws is the passive status 
quo, and typed throws the energetic challenger)
- even less average-joe-programmers than ever (on a topic that immensely 
impacts their everyday job)

Shouldn't the community elect a benevolent dictator that would settle this 
subject? The final choice has of course to be sensible, but also strong and 
sharp.

Gwendal

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

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Alejandro Martinez via swift-evolution]

Just to comment on the idea that a forum will pull the community
together and improve this situation. A good and recent (as in young
language) example of it is Rust
https://users.rust-lang.org/c/announcements . You can filter by that
category and see what the community is building, new libraries and
even calls for help to maintain them. Not saying that that specific
forum is the solution but just pointing that something different that
the mailing list would help. Also there is already a lot of people
that doesn't chime in in this discussions because they are not
interested in dealing with a mailing list (you can see it easily with
recent conversations that happen in GitHub instead of here).

I also like how the standard Go packages look, a rich set of
functionality *out of the box*. I really like that, is basically how
Apple platforms are always so nice to develop on with Foundation been
amazing. But unless the Core Team can oversee the development and
design of such tools I personally wouldn't feel confortable shipping
them with the rest of Swift. And it doesn't have to be, with
improvements on SPM there shouldn't be a big difference between
something that ships with Swift and a 3rd party package (apart from
being installed on the OS instead of coming with your binary I guess).
With that and having the community together, and a good place to
highlight them, I feel like the de facto standard libs are gonna pop
up with some time and care. Then and only ten would make sense to
consider making them part of the oficial distribution. (unless
obviously the Core Team would triple in size and they had infinite
time to do all of it, but then we also like when they improve the
language and tooling, can't have it all ^^)

Another thing that this list has to consider when not receiving
feedback on this kind of thing is that a lot of the Swift community is
more the iOS community, and that already has a lot of necessities
solved with other package manager, indexes, website that showcase
libs, newsletters, etc. The difficulty here is grow the part of the
community that is not iOS (or Apple platform) centric, which is key
for the future of world dominance.

Cheers


On Thu, Nov 9, 2017 at 8:54 AM, Kelvin Ma via swift-evolution
 wrote:
> i’m not one to applaud everything go does but its extended standard library
> seems nice
>
> On Thu, Nov 9, 2017 at 2:24 AM, Nick Keets via swift-evolution
>  wrote:
>>
>> I think there are two ideas discussed in this thread at the same time. One
>> is for a more extended standard library, that is developed and shipped as
>> part of the language. This is similar to what Python, Go and other languages
>> are doing. The second is for a more wide collection of packages, developed
>> by 3rd parties and not included with the language. This is similar to npm,
>> PyPI, etc.
>>
>> If I understood it correctly, the original proposal is about the first
>> idea and I don't think an "open market" approach works well for this. As for
>> what should be included, I find Go to be a nice example, that could be used
>> as a starting point:
>>
>> https://golang.org/pkg/
>>
>> To summarize, it includes:
>> - archival and compression formats (tar, zip, gzip, ...)
>
>
> will be an open problem to port zlib to Swift, but it’s doable
>
>>
>> - a few data structures
>
>
> lots of incomplete implementations floating around GitHub, none really stand
> out because i feel like most people have gotten used to rolling their own
> since we still don’t have a Swift equivalent of std::priority_queue. at this
> point i just have Queue.swift file lying around that I copy and paste
> whenever i need it. which is bad.
>
>>
>> - cryptographic functions (including hashes and random numbers)
>
>
> This is being talked about right now, mostly about random number generation,
> less on cryptography since it’s really easy to mess that up
>
>>
>> - sqlite and basic database drivers support
>> - various data encodings (CSV, XML, JSON, ...)
>
>
> I have an Linux-compatible XML library in progress, last I remember the
> Foundation class didn’t work on Linux
>
>>
>> - some stuff used internally by the go tools (AST trees, debugging
>> symbols)
>> - basic graphics and image support
>
>
> i maintain a Swift PNG codec, and am developing a pure Swift JPEG codec
>
>>
>> - basic text and HTML templates
>
>
> could really use these, don’t know of any cross-platform Swift libraries for
> these
>
>>
>> - math and bignums
>
>
> peep https://github.com/attaswift/BigInt and
> https://github.com/xwu/NumericAnnex
>
>>
>> - networking and HTTP support (client and server)
>
>
> isn’t there a server working group?
>
>>
>> - OS support (including path handling, command line flags etc)
>
>
> YES. currently working on a new URI type to replace the Foundation one which
> is really just a wrapper around NSURL which is in turn a wrapper around
> CFURL. which is bad.
>
>>
>> - Miscellanous stuff like dates, 

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Adrian Zubarev via swift-evolution]

Hello Ted, would you mind opening a new thread and post an update about the 
forum and maybe answer a few minor questions like:
- what is currently planned?
- in which timeframe we *might* see the forum finally happening (don’t have to 
be a promise)?
- what happens to old mailing lists? (I’d say put a public archive somewhere, 
maybe slightly better formatted than the mailing list is, but do not spam new 
categories so that we can start with a fresh and clean forum. I also wouldn’t 
bother with migrating old users to new accounts. If I’m interested in 
contribution I can take a minute and create a new forum account. I mean we’re 
not trying to sell here anything, so this shouldn’t be a high priority right!?)

Thank you. :)


Am 9. November 2017 um 07:12:10, Ted Kremenek via swift-evolution 
(swift-evolution@swift.org) schrieb:



On Nov 8, 2017, at 12:08 PM, Kelvin Ma  wrote:



On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution 
 wrote:


On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution 
 wrote:



On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution 
 wrote:

I do not agree with Ted that only a few projects should be ranked, everyone, as 
it is in npm should be available. Only be graded according to recommendations.


I’m a bit confused.  I’m not sure what comments of mine I’m referring to.

Clearly I’m double confused.  That meant to read “I’m not sure what comments of 
mine *you* are referring to”.

I fully support having a broad spectrum of libraries that the community builds 
and uses.  Any library that we decide to make part of “core Swift” — IMHO at a 
mature point in a library’s evolution — would need to have high value to the 
majority of the community and would need to feel solid enough that we can lock 
it in for both source and binary compatibility, high quality of implementation 
with sustained maintenance, etc.

i mean I don’t think these approaches are incompatible. The “swift core” could 
just make the process of independent libraries getting started easier. Like 
right now there’s really no place to say “hey I just started a library project 
for X, and anyone who wants to be involved should contribute at Y github repo 
where it lives right now”. I’ve tried sending that on this list before and it 
didn’t really work because mailing lists aren’t really a good medium for that 
and no one wants the swift-evolution list getting clogged with project-specific 
messages most people don’t care about.


These are great points.

FWIW, I’m getting optimistic about moving to a forum soon.  Would you expect 
that a forum could provide a better vehicle than a mailing list to arrange 
communication and interest within the community around building libraries?  Not 
just doing shout outs for projects, but also doing possible API design review, 
etc.?

As an analogy, within Apple we have various mailing lists to review APIs, which 
is one mechanism used for different teams to co-review newly proposed APIs and 
consider how they compose together with other APIs.  It’s not always perfect, 
but it does help facilitate a culture of API review so that various APIs can be 
considered together and part of the same (or compatible) design philosophies.

One of the things that resonated to me from Dave DeLong’s proposal was a sense 
about having a set of libraries that are well-considered and their efforts 
coordinated.  While the coordination pitched in Dave’s proposal was about a 
focused effort on a particular set of libraries/features, coordination can also 
take the form of having a community that cares about building good APIs and can 
constructively discuss them.  This can be done while also completely factoring 
out whether or not those APIs are part of “core Swift”.  Further, shared API 
review wouldn’t necessarily be about making actual decisions — which is the 
case of swift-evolution when evaluating language and standard library changes — 
but offering advice.  Fundamentally the library author still stays in control 
of their library and APIs, but the community could help in shaping up the 
gestalt of what are considered well-crafted Swift APIs in general.

Of course the big difference here with this idea compared to Apple’s internal 
API review process is that for Apple the APIs it vends are intended to be 
shipped together, and thus they must work together.  In open source, however, 
efforts on various libraries are often (usually?) independent.  Projects are 
usually created independently by different authors, and while it may be 
desirable for APIs from various libraries to feel natural to work with 
together, it’s not a requirement on their construction in general.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

i’m not one to applaud everything go does but its extended standard library
seems nice

On Thu, Nov 9, 2017 at 2:24 AM, Nick Keets via swift-evolution <
swift-evolution@swift.org> wrote:

> I think there are two ideas discussed in this thread at the same time. One
> is for a more extended standard library, that is developed and shipped as
> part of the language. This is similar to what Python, Go and other
> languages are doing. The second is for a more wide collection of packages,
> developed by 3rd parties and not included with the language. This is
> similar to npm, PyPI, etc.
>
> If I understood it correctly, the original proposal is about the first
> idea and I don't think an "open market" approach works well for this. As
> for what should be included, I find Go to be a nice example, that could be
> used as a starting point:
>
> https://golang.org/pkg/
>
> To summarize, it includes:
> - archival and compression formats (tar, zip, gzip, ...)
>

will be an open problem to port zlib to Swift, but it’s doable


> - a few data structures
>

lots of incomplete implementations floating around GitHub, none really
stand out because i feel like most people have gotten used to rolling their
own since we still don’t have a Swift equivalent of std::priority_queue. at
this point i just have Queue.swift file lying around that I copy and paste
whenever i need it. which is bad.


> - cryptographic functions (including hashes and random numbers)
>

This is being talked about right now, mostly about random number
generation, less on cryptography since it’s really easy to mess that up


> - sqlite and basic database drivers support
> - various data encodings (CSV, XML, JSON, ...)
>

I have an Linux-compatible XML library
 in progress, last I remember the
Foundation class didn’t work on Linux


> - some stuff used internally by the go tools (AST trees, debugging symbols)
> - basic graphics and image support
>

i maintain a Swift PNG codec , and am
developing a pure Swift JPEG codec 


> - basic text and HTML templates
>

could really use these, don’t know of any cross-platform Swift libraries
for these


> - math and bignums
>

peep https://github.com/attaswift/BigInt and
https://github.com/xwu/NumericAnnex


> - networking and HTTP support (client and server)
>

isn’t there a server working group?


> - OS support (including path handling, command line flags etc)
>

YES. currently working on a new URI type 
to replace the Foundation one which is really just a wrapper around NSURL
which is in turn a wrapper around CFURL. which is bad.


> - Miscellanous stuff like dates, unicode, IO, string parsing, testing, etc.
>

yes


> Go considers all these packages part of the language and offers source
> compatibility guarantees for all of them. I find the availability of these
> packages and the fact that they are developed and maintained by the Go core
> team to be very powerful.
>
> We can debate what should be included and if these should be separate
> modules or not, but I think the key insight here is that they are a curated
> list of useful libraries that are developed and maintained together with
> the language.
>
>
> On Wed, Nov 8, 2017 at 9:37 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Nov 8, 2017, at 4:54 AM, Karl Wagner  wrote:
>>
>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> FWIW, Ben Cohen and I have been talking about possibly using Swift
>> packages as a way to seed out experimental ideas for extensions to the
>> Standard Library.  This would allow ideas to be trialed by real usage (a
>> complaint I’ve seen about some changes we’ve made to Swift in the past).
>> Users could build things on top of those libraries, knowing they are
>> available as packages, and if an API “graduates” to being part of the
>> Standard Library the user can then depend upon it being available there.
>> If it never graduates, however, the package remains around.
>>
>>
>> Yeah this is exactly the problem that the package manager is there to
>> solve, right? It’s supposed to make it ridiculously easy to integrate
>> libraries and manage your dependencies.
>>
>> The problem is that most people writing Swift code every day are doing it
>> to make graphical applications on iOS/macOS. SwiftPM doesn’t support those,
>> so if I want to test a library, it’s just a one-off thing that I play with
>> in a Playground.
>>
>>
>> I think that the best thing we could do to encourage people to write, use
>> and contribute to public libraries would be to improve the package manager.
>> SwiftPM is still basically a toy (or an interesting curiosity), until it
>> can actually be used in the projects most Swift devs get paid to work on
>> every day. Talking about it supporting a community is way 

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Thu, Nov 9, 2017 at 1:49 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Nov 7, 2017, at 5:54 PM, Dave DeLong via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hi Swift-Evolution,
> >
> > The Standard Library's goal is to be small and targeted. However, many
> aspects of Apple-provided frameworks need or offer opportunities for
> improvement or wholesale replacement. These enhancements lie beyond the
> scope of the Standard Library.
> >
> > To address this, we'd like to propose the idea of a "Non-Standard
> Library"; this would be a library that ships with a regular installation of
> Swift, but is not imported into .swift files by the compiler, unless
> explicitly requested by the developer.
> >
> > We are proposing a well-organized effort to parallel the Standard
> Library without putting additional implementation responsibilities onto the
> core team. This effort would mitigate what we see as platform-independent
> requirements that provide native Swift implementations that aren't burdened
> by Apple history.
>
> Hi Dave,
>
> As others have pointed out, we do already have a model for this sort of
> thing: the swift server working group.
>

i feel like the swift server working group is something that is very
difficult to reproduce because in 3 years of Swift it’s the only example of
such a project in existence


>
> That said, there is another analogy which gets closer to what you’re
> asking for: the Boost community for C++.  Boost was formed because the C++
> committee was too bogged down an wasn’t receptive to major library changes
> (at one point in time).  Boost has effectively parallel leadership from the
> C++ committee (though individuals are involved in both organizations of
> course).  This allows Boost to move faster, ship code, and get experience
> with it.
>
> One of the specifically nice things about Boost is that they (at least
> originally) focused on building out ideas, getting experience with them,
> and then bringing the libraries back to the standard.  The libraries
> occasionally undergo significant change when they are standardized, but the
> usage experience is unmatchable, particularly for very large and complex
> APIs.
>
>
the problem is boost doesn’t ship with C++ so people view it as just
another dependency, kind of like jQuery but more annoying because you have
to clone and build this giant support library (at least that was my
experience building Blender back in 2012). the C++ STL library or the
python support modules are probably closer to the distribution model I’d
like to see


> In the context of Swift, I think this sort of model could be very
> interesting, because there are really several different independent things
> going on: for a type like BigNum (for example) there are all the details of
> the implementation and design on the one hand, but then there is also the
> question of WHICH library it should ship with (Foundation or Swift or
> something else).  That second decision is much easier to make after the
> community has converged on a specific design.
>
> In any case, I think it would be a bad move for the official Swift
> distributions to ship code that hasn’t been through the evolution process.
> The idea of the Server working group is to delegate detailed design and
> iteration to a team of experts, but then have them bring back the API to
> evolution when the iteration is done and it is time to “standardize” it.  I
> think that this is a good model.
>
> -Chris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Thu, Nov 9, 2017 at 12:11 AM, Ted Kremenek  wrote:

>
>
> On Nov 8, 2017, at 12:08 PM, Kelvin Ma  wrote:
>
>
>
> On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I do not agree with Ted that only a few projects should be ranked,
>> everyone, as it is in npm should be available. Only be graded according to
>> recommendations.
>>
>>
>> I’m a bit confused.  I’m not sure what comments of mine I’m referring to.
>>
>>
>> Clearly I’m double confused.  That meant to read “I’m not sure what
>> comments of mine *you* are referring to”.
>>
>> I fully support having a broad spectrum of libraries that the community
>> builds and uses.  Any library that we decide to make part of “core Swift” —
>> IMHO at a mature point in a library’s evolution — would need to have high
>> value to the majority of the community and would need to feel solid enough
>> that we can lock it in for both source and binary compatibility, high
>> quality of implementation with sustained maintenance, etc.
>>
>
> i mean I don’t think these approaches are incompatible. The “swift core”
> could just make the process of independent libraries getting started
> easier. Like right now there’s really no place to say “hey I just started a
> library project for X, and anyone who wants to be involved should
> contribute at Y github repo where it lives right now”. I’ve tried sending
> that on this list before and it didn’t really work because mailing lists
> aren’t really a good medium for that and no one wants the swift-evolution
> list getting clogged with project-specific messages most people don’t care
> about.
>
>
> These are great points.
>
> FWIW, I’m getting optimistic about moving to a forum soon.  Would you
> expect that a forum could provide a better vehicle than a mailing list to
> arrange communication and interest within the community around building
> libraries?  Not just doing shout outs for projects, but also doing possible
> API design review, etc.?
>

this forum thing has been talked about for almost a year now and i am for
real convinced it will never happen tbh. if it did, it would probably be
more conducive but ultimately it comes down to the number of people
interested because right now it’s like there’s only a handful of people on
this list who want to write open source libraries (or really anything
without a graphical interface since it’s basically 90% ios devs here). will
a forum encourage more people to get involved in the language? maybe, for
me it took a really long time to actually sign up for this mailing list and
talk in it because mailing lists are just not easy to get involved in


>
> As an analogy, within Apple we have various mailing lists to review APIs,
> which is one mechanism used for different teams to co-review newly proposed
> APIs and consider how they compose together with other APIs.  It’s not
> always perfect, but it does help facilitate a culture of API review so that
> various APIs can be considered together and part of the same (or
> compatible) design philosophies.
>
> One of the things that resonated to me from Dave DeLong’s proposal was a
> sense about having a set of libraries that are well-considered and their
> efforts coordinated.  While the coordination pitched in Dave’s proposal was
> about a focused effort on a particular set of libraries/features,
> coordination can also take the form of having a community that cares about
> building good APIs and can constructively discuss them.  This can be done
> while also completely factoring out whether or not those APIs are part of
> “core Swift”.  Further, shared API review wouldn’t necessarily be about
> making actual decisions — which is the case of swift-evolution when
> evaluating language and standard library changes — but offering advice.
> Fundamentally the library author still stays in control of their library
> and APIs, but the community could help in shaping up the gestalt of what
> are considered well-crafted Swift APIs in general.
>
> Of course the big difference here with this idea compared to Apple’s
> internal API review process is that for Apple the APIs it vends are
> intended to be shipped together, and thus they must work together.  In open
> source, however, efforts on various libraries are often (usually?)
> independent.  Projects are usually created independently by different
> authors, and while it may be desirable for APIs from various libraries to
> feel natural to work with together, it’s not a requirement on their
> construction in general.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Nick Keets via swift-evolution]

I think there are two ideas discussed in this thread at the same time. One
is for a more extended standard library, that is developed and shipped as
part of the language. This is similar to what Python, Go and other
languages are doing. The second is for a more wide collection of packages,
developed by 3rd parties and not included with the language. This is
similar to npm, PyPI, etc.

If I understood it correctly, the original proposal is about the first idea
and I don't think an "open market" approach works well for this. As for
what should be included, I find Go to be a nice example, that could be used
as a starting point:

https://golang.org/pkg/

To summarize, it includes:
- archival and compression formats (tar, zip, gzip, ...)
- a few data structures
- cryptographic functions (including hashes and random numbers)
- sqlite and basic database drivers support
- various data encodings (CSV, XML, JSON, ...)
- some stuff used internally by the go tools (AST trees, debugging symbols)
- basic graphics and image support
- basic text and HTML templates
- math and bignums
- networking and HTTP support (client and server)
- OS support (including path handling, command line flags etc)
- Miscellanous stuff like dates, unicode, IO, string parsing, testing, etc.

Go considers all these packages part of the language and offers source
compatibility guarantees for all of them. I find the availability of these
packages and the fact that they are developed and maintained by the Go core
team to be very powerful.

We can debate what should be included and if these should be separate
modules or not, but I think the key insight here is that they are a curated
list of useful libraries that are developed and maintained together with
the language.


On Wed, Nov 8, 2017 at 9:37 PM, Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Nov 8, 2017, at 4:54 AM, Karl Wagner  wrote:
>
> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> FWIW, Ben Cohen and I have been talking about possibly using Swift
> packages as a way to seed out experimental ideas for extensions to the
> Standard Library.  This would allow ideas to be trialed by real usage (a
> complaint I’ve seen about some changes we’ve made to Swift in the past).
> Users could build things on top of those libraries, knowing they are
> available as packages, and if an API “graduates” to being part of the
> Standard Library the user can then depend upon it being available there.
> If it never graduates, however, the package remains around.
>
>
> Yeah this is exactly the problem that the package manager is there to
> solve, right? It’s supposed to make it ridiculously easy to integrate
> libraries and manage your dependencies.
>
> The problem is that most people writing Swift code every day are doing it
> to make graphical applications on iOS/macOS. SwiftPM doesn’t support those,
> so if I want to test a library, it’s just a one-off thing that I play with
> in a Playground.
>
>
> I think that the best thing we could do to encourage people to write, use
> and contribute to public libraries would be to improve the package manager.
> SwiftPM is still basically a toy (or an interesting curiosity), until it
> can actually be used in the projects most Swift devs get paid to work on
> every day. Talking about it supporting a community is way premature; it’s
> not even close to ready to taking on that responsibility, IMO.
>
>
> I agree that the tooling support around SwiftPM is not sufficiently
> advanced yet to support this for everybody.  Further, I don’t think there
> would be a need to preclude other ways to share libraries for this purpose,
> even if the SwiftPM tooling support was more mature.
>
> The primary point I wanted to make was more about the model itself.  I’d
> prefer the community grow up a set of libraries that trialed and used
> before focusing on prematurely baking them into the core Swift distribution.
>
> ___
> 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