Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[Howard Lovatt via swift-evolution]

Not a big deal either way, but I prefer the 2nd (nil) form and therefore
would like to see the 1st form go. It would make Swift more consistent,
consider:

let o: Int? // Looks like nil is assigned.
if someTest {
o = 1 // Why isn't this an error? (OK I know why - but it looks odd.)
} else {
o = nil
}


Whilst the above works it is weird because if you are aware that o: Int?
normally assigns nil then the above looks like o, which is a let, is
assigned to twice. If you do the equivalent of the above for a non-optional
it is an error.

  -- Howard.

On 8 November 2017 at 07:54, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Same here, but I wouldn’t care much if it were gone.
>
>
> Am 7. November 2017 um 21:40:56, David Hart via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Yeah, I use the first form constantly.
>
> > On 6 Nov 2017, at 23:33, 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
>
> ___
> 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-0187: Introduce Sequence.filterMap(_:)

[Howard Lovatt via swift-evolution]

The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and
runs through November 14th, 2017.  The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/
proposals/0187-introduce-filtermap.md


• What is your evaluation of the proposal?
Worthwhile since there is a potential problem. However I am not convinced:

  1. About the name, it sounds like it filters and then maps rather than
what it really does which is map and then filter. Also, what does it
filter? How about mapFilterOptional (which is similar to Haskel name where
Maybe is equivalent of Optional).

  2. There is a more general problem of automatically wrapping a
non-optional in an optional; which this is a symptom off. So rather than
fix up the symptom, why not fix the problem. In particular; why not stop
the automatic conversion of a value to an optional, instead provide a value
to optional operator (the reverse of !). Say a trailing ~, used like 5~ to
mean Optional.some(5). ~ chosen because it is like an S, for some, on it's
side.

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

• Does this proposal fit well with the feel and direction of Swift?
Yes and no - see comments above. In particular automatic conversions are
not common in Swift. The conversion of a value to an optional automatically
therefore stands out.

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

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

  -- Howard.

On 8 November 2017 at 10:23, John McCall  wrote:

> Hello, Swift community!
>
> The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and
> runs through November 14th, 2017.  The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0187-introduce-filtermap.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/0187-introduce-filtermap.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.
>
> John McCall
> Review Manager
>
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Question] Why does `beginAsync` rethrow errors?

[omochi.metaru via swift-evolution]

I totally agree Yuta's suggestion.
beginAsync does not have to accept function which throws.

> Adam

I don't think that C# style async void function invodation matchs swift.

If we can do, following code can be compile.

```swift
async func sendMessage() -> Void { ... }

func onButtonClick() {
sendMessage()
showAlert("message sent")
}
```

But in this case, the logic actually programmer desired is
showing alert after sendMessage completed.
Above style code is not easy readable about execution fall through
without waiting completion of sendMessage to showAlert.
With this rule, compiler can not help us to find such mistaken code.

This seems like unchecked exception problem in other languages.
Keep starting asynchronous invodation explicit suck like
throwing function invocation explicitly marked with `try` or `do`.

2017年11月8日(水) 13:28 Adam Kemp via swift-evolution :

> I think I agree with this. beginAsync is similar to C#’s async void
> functions, and one of the gotchas in C# is that it is never safe to allow
> an exception to be thrown from an async void function. The reason is that
> if the exception happens after the continuation then there won’t be any
> application code above it to catch that exception. As a result, the built
> in behavior is to immediately crash the app.
>
> This is unavoidable in C# where it’s impossible to write a function that
> is guaranteed not to throw. The semantics of exception throwing don’t allow
> for that in C#.
>
> Swift has the advantage in this case of being able to statically verify
> that a function doesn’t throw so we can do better.
>
> So I would argue in favor of not allowing beginAsync to throw at all.
>
> FWIW, I also still think it would be better if we allowed for async void
> functions instead of requiring beginAsync in the first place. If I had my
> way then we would have async void, but an async void would not be allowed
> to throw.
>
> > On Nov 7, 2017, at 7:04 PM, Yuta Koshizawa via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Although I posted about this topic before, let me post this again
> > because I think it is important and I have received just few replies.
> > Sorry if I missed some discussion about it.
> >
> > In the proposal (
> > https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 ),
> > `beginAsync` has the following signature.
> >
> > ```
> > func beginAsync(_ body: () async throws -> Void) rethrows -> Void
> > ```
> >
> > However, I think it is better to forbid `body` to throw errors, that
> > is to say, to change its signature to the following one.
> >
> > ```
> > func beginAsync(_ body: () async -> Void) -> Void
> > ```
> >
> > Even if `beginAsync` allows that `body` throws errors, it can rethrow
> > ones which are thrown before only first `await` call. In following
> > cases, `beginAsync` just has to make the program crash when `foo`
> > throws an error. It breaks safety for error handing by typed
> > propagation realized by `throws/try`.
> >
> > ```
> > // throws errors asynchronously
> > func foo() async throws -> Int { ... }
> >
> > do {
> >beginAsync {
> >let a = try await foo()
> >// uses `a` here
> >}
> > } catch _ {
> >// never reaches here
> > }
> > ```
> >
> > If `beginAsync` forbid `body` to throw errors, it can be detected as a
> > compilation error and is possible to fix it as follows.
> >
> > ```
> > beginAsync {
> >do {
> >let a = try await foo()
> >// uses `a` here
> >} catch _ {
> >//  error handling
> >}
> > }
> > ```
> >
> > And even when we want to write `try` calls in `beginAsync` before
> > first `await` call, those lines can be moved before the `beginAsync`
> > call.
> >
> > ```
> > // before ( `beginAsync` marked with `rethrows` )
> > do {
> >beginAsync {
> >let a = try bar()
> >let b = try baz()
> >let c = await qux(a, b)
> >// uses `c` here
> >}
> > catch _ {
> >// error handling
> > }
> >
> > // after ( `beginAsync` without `rethrows` )
> > do {
> >let a = try bar()
> >let b = try baz()
> >beginAsync {
> >let c = await qux(a, b)
> >// uses `c` here
> >}
> > catch _ {
> >// error handling
> > }
> > ```
> >
> > So the functionalities of `beginAsync` seems be kept even if it forbid
> > `body` to throw errors.
> >
> > What do you think about it?
> >
> > --
> > Yuta
> > ___
> > 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
>
-- 
omochimetaru
___
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(_:)

[John McCall via swift-evolution]

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

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?

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 a way that invokes optional hoisting, 
> it'll match this overload instead and warn them.
> 
>> • How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> A quick reading, and a couple of minutes testing overload behavior with 
> availability attributes (to confirm that we can't simply use 'unavailable' 
> for this).
> 
> -Kevin Ballard
> 
> ___
> 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] [Question] Why does `beginAsync` rethrow errors?

[Adam Kemp via swift-evolution]

I think I agree with this. beginAsync is similar to C#’s async void functions, 
and one of the gotchas in C# is that it is never safe to allow an exception to 
be thrown from an async void function. The reason is that if the exception 
happens after the continuation then there won’t be any application code above 
it to catch that exception. As a result, the built in behavior is to 
immediately crash the app.

This is unavoidable in C# where it’s impossible to write a function that is 
guaranteed not to throw. The semantics of exception throwing don’t allow for 
that in C#.

Swift has the advantage in this case of being able to statically verify that a 
function doesn’t throw so we can do better.

So I would argue in favor of not allowing beginAsync to throw at all.

FWIW, I also still think it would be better if we allowed for async void 
functions instead of requiring beginAsync in the first place. If I had my way 
then we would have async void, but an async void would not be allowed to throw.

> On Nov 7, 2017, at 7:04 PM, Yuta Koshizawa via swift-evolution 
>  wrote:
> 
> Although I posted about this topic before, let me post this again
> because I think it is important and I have received just few replies.
> Sorry if I missed some discussion about it.
> 
> In the proposal (
> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 ),
> `beginAsync` has the following signature.
> 
> ```
> func beginAsync(_ body: () async throws -> Void) rethrows -> Void
> ```
> 
> However, I think it is better to forbid `body` to throw errors, that
> is to say, to change its signature to the following one.
> 
> ```
> func beginAsync(_ body: () async -> Void) -> Void
> ```
> 
> Even if `beginAsync` allows that `body` throws errors, it can rethrow
> ones which are thrown before only first `await` call. In following
> cases, `beginAsync` just has to make the program crash when `foo`
> throws an error. It breaks safety for error handing by typed
> propagation realized by `throws/try`.
> 
> ```
> // throws errors asynchronously
> func foo() async throws -> Int { ... }
> 
> do {
>beginAsync {
>let a = try await foo()
>// uses `a` here
>}
> } catch _ {
>// never reaches here
> }
> ```
> 
> If `beginAsync` forbid `body` to throw errors, it can be detected as a
> compilation error and is possible to fix it as follows.
> 
> ```
> beginAsync {
>do {
>let a = try await foo()
>// uses `a` here
>} catch _ {
>//  error handling
>}
> }
> ```
> 
> And even when we want to write `try` calls in `beginAsync` before
> first `await` call, those lines can be moved before the `beginAsync`
> call.
> 
> ```
> // before ( `beginAsync` marked with `rethrows` )
> do {
>beginAsync {
>let a = try bar()
>let b = try baz()
>let c = await qux(a, b)
>// uses `c` here
>}
> catch _ {
>// error handling
> }
> 
> // after ( `beginAsync` without `rethrows` )
> do {
>let a = try bar()
>let b = try baz()
>beginAsync {
>let c = await qux(a, b)
>// uses `c` here
>}
> catch _ {
>// error handling
> }
> ```
> 
> So the functionalities of `beginAsync` seems be kept even if it forbid
> `body` to throw errors.
> 
> What do you think about it?
> 
> --
> Yuta
> ___
> 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] [Question] Why does `beginAsync` rethrow errors?

[Yuta Koshizawa via swift-evolution]

Although I posted about this topic before, let me post this again
because I think it is important and I have received just few replies.
Sorry if I missed some discussion about it.

In the proposal (
https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619 ),
`beginAsync` has the following signature.

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

However, I think it is better to forbid `body` to throw errors, that
is to say, to change its signature to the following one.

```
func beginAsync(_ body: () async -> Void) -> Void
```

Even if `beginAsync` allows that `body` throws errors, it can rethrow
ones which are thrown before only first `await` call. In following
cases, `beginAsync` just has to make the program crash when `foo`
throws an error. It breaks safety for error handing by typed
propagation realized by `throws/try`.

```
// throws errors asynchronously
func foo() async throws -> Int { ... }

do {
beginAsync {
let a = try await foo()
// uses `a` here
}
} catch _ {
// never reaches here
}
```

If `beginAsync` forbid `body` to throw errors, it can be detected as a
compilation error and is possible to fix it as follows.

```
beginAsync {
do {
let a = try await foo()
// uses `a` here
} catch _ {
//  error handling
}
}
```

And even when we want to write `try` calls in `beginAsync` before
first `await` call, those lines can be moved before the `beginAsync`
call.

```
// before ( `beginAsync` marked with `rethrows` )
do {
beginAsync {
let a = try bar()
let b = try baz()
let c = await qux(a, b)
// uses `c` here
}
catch _ {
// error handling
}

// after ( `beginAsync` without `rethrows` )
do {
let a = try bar()
let b = try baz()
beginAsync {
let c = await qux(a, b)
// uses `c` here
}
catch _ {
// error handling
}
```

So the functionalities of `beginAsync` seems be kept even if it forbid
`body` to throw errors.

What do you think about it?

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

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

[Adam Kemp via swift-evolution]

> On Nov 7, 2017, at 6:05 PM, Jon Gilbert via swift-evolution 
>  wrote:
> 
> It’s easy to have projects where one Swift module is made up of numerous git 
> repos. You can silo who is allowed to touch your code that way even within 
> people working on a single module.

Why do you need to have multiple git repos contribute to a single module 
instead of having each repo produce its own module? I don’t understand why you 
would do that.

To me “module” implies “a cohesive set of code maintained by a single team”. I 
trust people on my team, and I can also see every change that goes into the 
projects I work on.

Again, if you don’t trust developers that are contributing code to your module 
then you have bigger problems than this. Proper module boundaries would help to 
address those problems.

> Having a class “partial” where anyone in the module can screw around is 
> dangerous and therefore un-Swifty. 

This is contradicted by the experience of a large community of C# developers 
who have been using partial classes for years without running into your 
hypothetical problems.

A search on GitHub shows over 5 million hits for “partial class” in C# code:
https://github.com/search?l=C%23=desc=%22partial+class%22=indexed=Code
 

There are over 2000 hits in the Rosyln codebase alone (Microsoft’s C# compiler):

https://github.com/dotnet/roslyn/search?q=%22partial+class%22= 


This is heavily used in the real world by professionals working on projects of 
all sizes.

I think we have to weigh the FUD against what we can observe actually happening 
in the wild when developers use a feature like this. The reality is that the 
things you’re concerned about are not actually problems in practice. They’re 
contrived hypotheticals.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jon Gilbert via swift-evolution]

On Nov 3, 2017, at 14:36, Adam Kemp via swift-evolution 
 wrote:
> 
> If you work with people who can’t follow conventions and would try to extend 
> partial classes from random places then I’m sorry. :)

This seems naive. 

Swift is based on the idea of making it impossible to do things the wrong way, 
because of Murphy’s Law.

You might get hired to clean up some total crap code that was created in a 
sweatshop overseas by people who never touched Swift before and only ever wrote 
in PHP 1.0 before that. I have seen this kind of thing all too often.

Then you have the fact that Swift is used increasingly in school environments, 
and I sure as heck don’t want some bully kid being able to inject pronz to 
display on my kid’s viewcontroller just because she wanted to use “parts” or 
“partials” (or whatever we end up calling it).

Then there are open source projects where all kinds of malicious things could 
be done with unbounded partiality, and people will hesitate to use this feature 
without being able to trust its safety.

My point is it’s not always a team of highly trained professional developers 
working on a project. It could be strangers you will never meet. Someone 
vindictive or stupid could also do something to deliberately or accidentally 
break code you worked. And when they blame you, then “those were private 
methods you used” would no longer be a valid excuse. 

I feel much better declaring the parts as a list, and that way you can 
command-click on them in XCode to jump to those other parts, and the 
initializer can make sure that all those parts can be found or else block 
compilation. 

Just my 0.02.

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

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

[Jon Gilbert via swift-evolution]

I like the ledger list idea better than saying “this class is partial” and now 
it can be extended anywhere.

Adam said below that, “you have to trust your fellow developers,” but that’s 
BS. You can’t merge a PR to master without approval, and some repos you have to 
PR from a fork. 

It’s easy to have projects where one Swift module is made up of numerous git 
repos. You can silo who is allowed to touch your code that way even within 
people working on a single module.

Having a class “partial” where anyone in the module can screw around is 
dangerous and therefore un-Swifty. 

If devs could be trusted then Swift and git would not even exist.

So I feel it has to be the ledger, guys :D Just saying.

J

> On Nov 2, 2017, at 18:37, Adam Kemp via swift-evolution 
>  wrote:
> 
> I will echo what several other people said in the previous discussion: you 
> have to trust your fellow developers. By declaring a class as “partial” you 
> are allowing that class to be extended elsewhere. Typically that would mean 
> in an adjacent file named ClassName.Foo.swift (next to ClassName.swift). It 
> should be highly discouraged to extend the class using partial from anywhere 
> else, and listing tools can enforce that if needed. But at the end of the day 
> if you can’t trust your fellow developers not to do that then you can’t trust 
> them not to add a new name to the ledger either.
> 
> And in case someone was wondering why I’m ok with this and not the 
> “classprivate" idea, the key difference here is that this is opt-in. I’m 
> still not ok with a random extension being able to access private fields of 
> any class by default. Partial classes should be an exception for specific use 
> cases, not a default behavior.
> 
>> On Nov 2, 2017, at 5:18 AM, Mike Kluev via swift-evolution 
>>  wrote:
>> 
>> to sum up. so far the feedback on this proposal was:
>> 
>> 1) generally in favour (e.g. to have ability of adding variables and 
>> accessing privates at all)
>> 
>> 2) the name "continuation" is used for something else
>> 
>> 3) why not to use partials as they are in c#
>> 
>> 4) having explicit names for continuations is unwanted because naming is hard
>> 
>> 5) the ledger list is unnecessary as anyone on the same module will be able 
>> to change it anyway - false feel of protection.
>> 
>> here are my thoughts on it.
>> 
>> 1) "generally in favour (e.g. to have ability of adding variables and 
>> accessing privates at all)"
>> -- great! thank you.
>> 
>> 2) "the name "continuation" is used for something else"
>> -- thought the same. let it be "part" instead of continuation
>> 
>> 3) "why not to use partials as they are in c#"
>> -- my belief here is that just because i made my type partial (for my own 
>> reasons, e.g. as a result of splitting a single-file class into a 
>> multi-file) it does not necessarily mean I want other developers of my team 
>> (on the same module) to add continuations / parts to my class. in other 
>> words, while there are the module boundaries (the building walls) i still 
>> want to see some partitions between the rooms of that building to have some 
>> privacy.
>> 
>> 4) "having explicit names for continuations is unwanted because naming is 
>> hard"
>> -- every time I am adding extension now I want to label it somehow to 
>> indicate it's purpose. if that extensions adds a protocol conformance (e.g. 
>> "extension ViewController: UITableViewDataSource") the problem is not as 
>> critical as the protocol (or the list of protocols) name itself can serve 
>> the purpose of such an indication. if there is no such a protocol 
>> conformance however i tend to add a "MARK: ThePurpose" or a comment 
>> ("extension ViewController /* ThePurpose */) and as the comments are not 
>> checked and get out of sync every time i do this i wish there was a a more 
>> explicit extension label in the language for this purpose. maybe that's just 
>> me.
>> 
>> 5) "the ledger list is unnecessary as anyone on the same module will be able 
>> to change it anyway - false feel of protection."
>> -- to this i can give the same response as in (3). here is another example 
>> that hopefully will clarify my point: we shall not really say that "private" 
>> in swift is useless and "internal" shall be used instead of it just because 
>> anyone in the same module can bypass it anyway: go to your class and change 
>> the source from "private" to "internal" for their own benefits, so why 
>> bother with private / fileprivate to begin with. so is true in regards to 
>> the ledger: yes, it is true that anyone on the team working on the same 
>> module has a physical ability to go to my class (the class who's sole 
>> maintainer and "owner" is myself) and mess around it, changing it's ledger 
>> along the way, or making it partial as in (3) or changing it's privates to 
>> internal, or adding variables, etc. it's just they shouldn't, at least not 
>> talking to me first. 

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

[Tino Heth via swift-evolution]

-1

I guess breaking existing code will be the show stopper for this proposal — but 
I generally think that compatibility is a poor rationale to stop an 
improvement, so my personal reasons are different:
The name is just wrong.
Just have a look at this simple example

extension Int {
func justImagineError() throws -> Int {
return self
}
}

let ints: [Int?] = [nil]

let result = ints.flatMap {
return try? $0?.justImagineError()
}
print(result)

If flatMap would really filter out nil values, this should yield an empty array 
as result — but the actual output is [nil]___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] JSONEncoder: Key strategies

[Norio Nomura via swift-evolution]

Hi Itai,

I see. I thought that the second reason you mentioned is so reasonable.
Apart from this proposal, if enum with String as RawValue is defined by
omitting StringLiteral, it would be a good idea to have a mechanism to
generate snake_case or a space delimited string.


2017-11-08 2:20 GMT+09:00 Itai Ferber :

> Hi Norio,
>
> There are two reasons that I think this is valuable over doing something
> in CodingKeys:
>
>1. The definition you give your coding keys affects all encoding
>formats. JSON is a format where snake_case can be relatively common, so the
>transformation makes a lot of sense there. For other formats, like plist
>files or otherwise, the transformation might not make as much sense.
>Instead of affecting all of your coding keys globally, this limits it to
>JSON.
>2. More importantly, this allows you to transform keys of things which
>you don’t necessarily own. If you’re working with types that you didn’t
>write (but which are expected to have snake_case keys nonetheless), this
>allows you to perform that transformation. If this were instead an
>annotation on CodingKeys directly, you wouldn’t be able to perform it
>on types you don’t directly own.
>
> — Itai
>
> On 6 Nov 2017, at 17:39, Norio Nomura via swift-evolution wrote:
>
> Hi Tony,
>
> Is it better for us to choose on `Codable` side whether `rawValue` of
> `CodingKeys` should be generated with snake_case?
> It seems to be more consistent with the current method of setting
> `rawValue` of `CodingKeys` on `Codable` side.
>
> Thanks,
> --
> @norio_nomura
>
> 2017-11-07 5:54 GMT+09:00 Tony Parker via swift-evolution <
> swift-evolution@swift.org>:
>
>> 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 

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

[BJ Homer via swift-evolution]

• What is your evaluation of the proposal?
I approve. This variant of ‘Sequence.flatMap’ is confusing to newcomers, and is 
inconsistent with the standard term-of-art usage of “flatMap”. People can learn 
what it means, but it continues to feel awkward. There will be some code churn, 
but it’s easily automatable and improves the clarity of the code. If we leave 
the existing spelling in place as deprecated, then we even preserve source 
compatibility.

• Is the problem being addressed significant enough to warrant a change to 
Swift?
I think so. The existing spelling of this functionality has three problems:
Discoverability: Users looking to filter out ‘nil’ values have to know to look 
for something that doesn’t say “filter”
Unexpected behavior: Users who are unfamiliar with the concept of Optionals as 
a Sequence-of-one have difficulty understanding why this is called “flatMap”. 
They don’t know what it does. I’ve seen this many times.
Brittleness: The functionality changes dramatically if the body of the function 
changes from returning an Optional to a Sequence. An example of this was given 
in the proposal, but here’s another one: 
struct Thing {
var name: String? // What if this becomes non-optional in the future?
}

// If Thing.name is optional, this returns an array of names (with nil filtered 
out)
// If Thing.name becomes non-optional, this now returns an array of all the 
characters in all the names, concatenated
things.flatMap { $0.name }

In general, changing from optional to non-optional causes compiler warnings in 
cases where something wasn’t expecting that. This isn’t likely a common 
problem, but it isn’t a great argument in defense of the current situation.


• Does this proposal fit well with the feel and direction of Swift?
Yes. Clear names are a common theme in Swift, and we have other proposals in 
Swift 5 with a similar goal.

• If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
It makes us behavior more like those other languages, reducing user surprise.

• How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I was in the process of writing up a similar proposal myself when this one came 
out. I’ve thought about this quite a bit, and I think it’s the right choice.


-BJ


> On Nov 7, 2017, at 4:23 PM, John McCall via swift-evolution 
>  wrote:
> 
> Hello, Swift community!
> 
> The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and runs 
> through November 14th, 2017.  The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.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/0187-introduce-filtermap.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.
> 
> John McCall
> 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] [Review] SE-0187: Introduce Sequence.filterMap(_:)

[Kevin Ballard via swift-evolution]

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). 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 a way that invokes optional
hoisting, it'll match this overload instead and warn them.
> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
A quick reading, and a couple of minutes testing overload behavior with
availability attributes (to confirm that we can't simply use
'unavailable' for this).
-Kevin Ballard

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

Re: [swift-evolution] JSONEncoder: Key strategies

[Zach Wolfe via swift-evolution]

+1. Would allow me to delete a ton of code in my current project.

> On Nov 6, 2017, at 2:54 PM, 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 performance 
> cost, as each string key has to be converted.
> case convertToSnakeCase
> 
> /// Provide a custom conversion to the key in the encoded JSON from 
> the keys specified by the encoded types.
> /// The full path to the current 

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

[John McCall via swift-evolution]

Hello, Swift community!

The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and runs 
through November 14th, 2017.  The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.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/0187-introduce-filtermap.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.

John McCall
Review Manager
___
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]

I’m with Ted on this one. 
I would also love to see the Swift ecosystem grow but I think that it has to 
happen with SPM. With improvements on SPM (as discussed in other threads) and 
having a proper index (imho Cocoapods webpage is the best one out there, with 
stats about docs, unit testing, downloads...) that makes finding libraries 
easier. 
But also a discussion forum where great libs can be shared and highlighted to 
the rest of the community and big community efforts coordinated. If you look at 
Rust is a great example, their forums attract the whole community (sadly not 
something the mailing list does) and big and important projects have come up 
from the community that have made a huge impact. With that in place and some 
libs out there maturing I’m sure that in the future the conversation to include 
battle tested code into an oficial distribution would be easier.

Sent from my iPad

> On 7 Nov 2017, at 21:58, Ted Kremenek via swift-evolution 
>  wrote:
> 
> Hi Dave,
> 
> Thanks for bringing up this topic.  This has been kicked around a little, and 
> we’re still exploring different models on how to extend Swift.
> 
> The server APIs work group is one operational model for the community to 
> build out a new set of core libraries.  That work group was formed out of the 
> observation that there were different implementations of the same thing being 
> created by different Swift on server efforts, and that those different 
> efforts should pool those resources together and standardize on some 
> fundamentals.
> 
> That analogy could work here.  However, it also has possible major downsides. 
>  It can be heavyweight, and also artificially raise the importance of certain 
> people’s library efforts over others by creating a formal work group whose 
> efforts are expected to eventually be incorporated into the core Swift 
> distribution.  It would also force a discussion up front of what even makes 
> sense to incorporate into the core Swift distribution, which might be 
> artificially constraining the exploration of the set of libraries to 
> implement.
> 
> I need to think about your idea more, but my first reaction is that my 
> preferred route is that the community builds these libraries, ideally using 
> Swift Packages, and through trial and use we evaluate those libraries and 
> then decide if they should be incorporated as part of the core distribution.  
> There’s many factors involved in deciding if they can be incorporated into 
> the core distribution, but all of those could be informed by actually 
> building libraries and see them getting used.
> 
> We could also figure out a way to possibly highlight these efforts to the 
> Swift community, maybe on swift-evolution or other means — but all with the 
> expectation that these libraries are not *necessarily* going to be 
> standardized as part of the core swift distribution.  I don’t think that’s 
> all that bad either; not every library will make sense to incorporate into 
> the core Swift distribution (e.g., they are highly domain specific) but still 
> supporting their development would be beneficial to the community.
> 
> Note that any change going into the Swift core distribution inevitably 
> involves swift-evolution and the core team.  Changes going into the core 
> Swift distribution must meet a very high bar as far as implementation and 
> design, the confidence we have into committing to specific APIs (especially 
> since we’ll have ABI stability in Swift 5), and other factors.  Thus this 
> will not really alleviate much burden on the Core team or on the community — 
> one of the core goals of your proposal.  Further, incorporating all those 
> concerns up front when building libraries might be counterproductive.
> 
> 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.
> 
> One thing that resonates me in what you propose is about having a 
> “well-organized effort” whose aim is to make these libraries feel cohesive 
> and implemented well.  However, given that many of these naturally fall 
> somewhere in the spectrum of responsibilities within the Standard Library and 
> Foundation, I think it is self-misleading to think that the Core Team or 
> others would not be involved in these efforts if the intention is to possibly 
> incorporate these one day into the core Swift distribution.  There also may 
> be other ways to achieve that level of cohesion in API design, such as 
> through 

Re: [swift-evolution] JSONEncoder: Key strategies

[Mike Kluev via swift-evolution]

a big fat -1. sorry.

imho, this is barking up the wrong tree and things like converting from
camel case / snake case / removal underscores/ capitalization / etc, etc
shall not be part of foundation. even if people in the labs asking for
that. third party library - probably.

more easy way to handle keys customization would be nice, last i checked it
was "all or nothing", whenever i wanted to customise a single key i had to
do them all and the source tripled in size. something simple to avoid that
would be enough, imho.

Mike

on Mon, 06 Nov 2017 12:54:38 -0800 Tony Parker 
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  t/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
>
.
___
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 7, 2017, at 2:14 PM, Dave DeLong  wrote:
> 
> 
> 
>>> On Nov 7, 2017, at 3:12 PM, David Sweeris  wrote:
>>> 
>>> 
>>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution 
>>>  wrote:
>>> 
>>> Hi Dave,
>>> 
>>> Thanks for bringing up this topic.  This has been kicked around a little, 
>>> and we’re still exploring different models on how to extend Swift.
>>> 
>>> The server APIs work group is one operational model for the community to 
>>> build out a new set of core libraries.  That work group was formed out of 
>>> the observation that there were different implementations of the same thing 
>>> being created by different Swift on server efforts, and that those 
>>> different efforts should pool those resources together and standardize on 
>>> some fundamentals.
>>> 
>>> That analogy could work here.  However, it also has possible major 
>>> downsides.  It can be heavyweight, and also artificially raise the 
>>> importance of certain people’s library efforts over others by creating a 
>>> formal work group whose efforts are expected to eventually be incorporated 
>>> into the core Swift distribution.  It would also force a discussion up 
>>> front of what even makes sense to incorporate into the core Swift 
>>> distribution, which might be artificially constraining the exploration of 
>>> the set of libraries to implement.
>>> 
>>> I need to think about your idea more, but my first reaction is that my 
>>> preferred route is that the community builds these libraries, ideally using 
>>> Swift Packages, and through trial and use we evaluate those libraries and 
>>> then decide if they should be incorporated as part of the core 
>>> distribution.  There’s many factors involved in deciding if they can be 
>>> incorporated into the core distribution, but all of those could be informed 
>>> by actually building libraries and see them getting used.
>>> 
>>> We could also figure out a way to possibly highlight these efforts to the 
>>> Swift community, maybe on swift-evolution or other means — but all with the 
>>> expectation that these libraries are not *necessarily* going to be 
>>> standardized as part of the core swift distribution.  I don’t think that’s 
>>> all that bad either; not every library will make sense to incorporate into 
>>> the core Swift distribution (e.g., they are highly domain specific) but 
>>> still supporting their development would be beneficial to the community.
>>> 
>>> Note that any change going into the Swift core distribution inevitably 
>>> involves swift-evolution and the core team.  Changes going into the core 
>>> Swift distribution must meet a very high bar as far as implementation and 
>>> design, the confidence we have into committing to specific APIs (especially 
>>> since we’ll have ABI stability in Swift 5), and other factors.  Thus this 
>>> will not really alleviate much burden on the Core team or on the community 
>>> — one of the core goals of your proposal.  Further, incorporating all those 
>>> concerns up front when building libraries might be counterproductive.
>>> 
>>> 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.
>>> 
>>> One thing that resonates me in what you propose is about having a 
>>> “well-organized effort” whose aim is to make these libraries feel cohesive 
>>> and implemented well.  However, given that many of these naturally fall 
>>> somewhere in the spectrum of responsibilities within the Standard Library 
>>> and Foundation, I think it is self-misleading to think that the Core Team 
>>> or others would not be involved in these efforts if the intention is to 
>>> possibly incorporate these one day into the core Swift distribution.  There 
>>> also may be other ways to achieve that level of cohesion in API design, 
>>> such as through community discussion (possibly via the Swift.org mailing 
>>> lists/forums).  This discussion would not necessarily be the same as the 
>>> path to “ratification” of a library into core Swift, but a step that could 
>>> benefit many library authors (including considering ideas one day 
>>> incorporated into the core swift).  With such a mechanism many library 
>>> authors could benefit even if they do not intend to have the library as 
>>> part of the core distribution.
>>> 
>>> My apologies that these are all hand-wavy ideas, but I’m trying to paint a 
>>> possible alternative way to achieve 

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

[Jonathan Hull via swift-evolution]

> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> We could also figure out a way to possibly highlight these efforts to the 
> Swift community, maybe on swift-evolution or other means — but all with the 
> expectation that these libraries are not *necessarily* going to be 
> standardized as part of the core swift distribution.  I don’t think that’s 
> all that bad either; not every library will make sense to incorporate into 
> the core Swift distribution (e.g., they are highly domain specific) but still 
> supporting their development would be beneficial to the community.

What I really want to see is a Code Store in Xcode (kind of like an app store 
for Swift packages).  Basically, you would hit “Add Package” in the 
sidebar/menu and a sheet pops up where you can search for and view various 
packages.  You then hit an “Add” button in the sheet, and it would add the 
package to your project.  To remove a package you would select it and hit 
delete.

Selecting a package in the sidebar would let you set some settings (e.g. select 
a specific version), and view documentation.  Xcode would manage the files for 
you behind the scenes.

I know that is out of scope for Evolution, but I just wanted to mention it, 
since it might help with the visibility issue.

Thanks,
Jon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave DeLong via swift-evolution]

> On Nov 7, 2017, at 3:12 PM, David Sweeris  wrote:
> 
>> 
>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution 
>> > wrote:
>> 
>> Hi Dave,
>> 
>> Thanks for bringing up this topic.  This has been kicked around a little, 
>> and we’re still exploring different models on how to extend Swift.
>> 
>> The server APIs work group is one operational model for the community to 
>> build out a new set of core libraries.  That work group was formed out of 
>> the observation that there were different implementations of the same thing 
>> being created by different Swift on server efforts, and that those different 
>> efforts should pool those resources together and standardize on some 
>> fundamentals.
>> 
>> That analogy could work here.  However, it also has possible major 
>> downsides.  It can be heavyweight, and also artificially raise the 
>> importance of certain people’s library efforts over others by creating a 
>> formal work group whose efforts are expected to eventually be incorporated 
>> into the core Swift distribution.  It would also force a discussion up front 
>> of what even makes sense to incorporate into the core Swift distribution, 
>> which might be artificially constraining the exploration of the set of 
>> libraries to implement.
>> 
>> I need to think about your idea more, but my first reaction is that my 
>> preferred route is that the community builds these libraries, ideally using 
>> Swift Packages, and through trial and use we evaluate those libraries and 
>> then decide if they should be incorporated as part of the core distribution. 
>>  There’s many factors involved in deciding if they can be incorporated into 
>> the core distribution, but all of those could be informed by actually 
>> building libraries and see them getting used.
>> 
>> We could also figure out a way to possibly highlight these efforts to the 
>> Swift community, maybe on swift-evolution or other means — but all with the 
>> expectation that these libraries are not *necessarily* going to be 
>> standardized as part of the core swift distribution.  I don’t think that’s 
>> all that bad either; not every library will make sense to incorporate into 
>> the core Swift distribution (e.g., they are highly domain specific) but 
>> still supporting their development would be beneficial to the community.
>> 
>> Note that any change going into the Swift core distribution inevitably 
>> involves swift-evolution and the core team.  Changes going into the core 
>> Swift distribution must meet a very high bar as far as implementation and 
>> design, the confidence we have into committing to specific APIs (especially 
>> since we’ll have ABI stability in Swift 5), and other factors.  Thus this 
>> will not really alleviate much burden on the Core team or on the community — 
>> one of the core goals of your proposal.  Further, incorporating all those 
>> concerns up front when building libraries might be counterproductive.
>> 
>> 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.
>> 
>> One thing that resonates me in what you propose is about having a 
>> “well-organized effort” whose aim is to make these libraries feel cohesive 
>> and implemented well.  However, given that many of these naturally fall 
>> somewhere in the spectrum of responsibilities within the Standard Library 
>> and Foundation, I think it is self-misleading to think that the Core Team or 
>> others would not be involved in these efforts if the intention is to 
>> possibly incorporate these one day into the core Swift distribution.  There 
>> also may be other ways to achieve that level of cohesion in API design, such 
>> as through community discussion (possibly via the Swift.org 
>>  mailing lists/forums).  This discussion would not 
>> necessarily be the same as the path to “ratification” of a library into core 
>> Swift, but a step that could benefit many library authors (including 
>> considering ideas one day incorporated into the core swift).  With such a 
>> mechanism many library authors could benefit even if they do not intend to 
>> have the library as part of the core distribution.
>> 
>> My apologies that these are all hand-wavy ideas, but I’m trying to paint a 
>> possible alternative way to achieve your goal of more library evolution for 
>> Swift without having such a formal work group that may be too 

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

[David Sweeris via swift-evolution]

> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> Hi Dave,
> 
> Thanks for bringing up this topic.  This has been kicked around a little, and 
> we’re still exploring different models on how to extend Swift.
> 
> The server APIs work group is one operational model for the community to 
> build out a new set of core libraries.  That work group was formed out of the 
> observation that there were different implementations of the same thing being 
> created by different Swift on server efforts, and that those different 
> efforts should pool those resources together and standardize on some 
> fundamentals.
> 
> That analogy could work here.  However, it also has possible major downsides. 
>  It can be heavyweight, and also artificially raise the importance of certain 
> people’s library efforts over others by creating a formal work group whose 
> efforts are expected to eventually be incorporated into the core Swift 
> distribution.  It would also force a discussion up front of what even makes 
> sense to incorporate into the core Swift distribution, which might be 
> artificially constraining the exploration of the set of libraries to 
> implement.
> 
> I need to think about your idea more, but my first reaction is that my 
> preferred route is that the community builds these libraries, ideally using 
> Swift Packages, and through trial and use we evaluate those libraries and 
> then decide if they should be incorporated as part of the core distribution.  
> There’s many factors involved in deciding if they can be incorporated into 
> the core distribution, but all of those could be informed by actually 
> building libraries and see them getting used.
> 
> We could also figure out a way to possibly highlight these efforts to the 
> Swift community, maybe on swift-evolution or other means — but all with the 
> expectation that these libraries are not *necessarily* going to be 
> standardized as part of the core swift distribution.  I don’t think that’s 
> all that bad either; not every library will make sense to incorporate into 
> the core Swift distribution (e.g., they are highly domain specific) but still 
> supporting their development would be beneficial to the community.
> 
> Note that any change going into the Swift core distribution inevitably 
> involves swift-evolution and the core team.  Changes going into the core 
> Swift distribution must meet a very high bar as far as implementation and 
> design, the confidence we have into committing to specific APIs (especially 
> since we’ll have ABI stability in Swift 5), and other factors.  Thus this 
> will not really alleviate much burden on the Core team or on the community — 
> one of the core goals of your proposal.  Further, incorporating all those 
> concerns up front when building libraries might be counterproductive.
> 
> 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.
> 
> One thing that resonates me in what you propose is about having a 
> “well-organized effort” whose aim is to make these libraries feel cohesive 
> and implemented well.  However, given that many of these naturally fall 
> somewhere in the spectrum of responsibilities within the Standard Library and 
> Foundation, I think it is self-misleading to think that the Core Team or 
> others would not be involved in these efforts if the intention is to possibly 
> incorporate these one day into the core Swift distribution.  There also may 
> be other ways to achieve that level of cohesion in API design, such as 
> through community discussion (possibly via the Swift.org  
> mailing lists/forums).  This discussion would not necessarily be the same as 
> the path to “ratification” of a library into core Swift, but a step that 
> could benefit many library authors (including considering ideas one day 
> incorporated into the core swift).  With such a mechanism many library 
> authors could benefit even if they do not intend to have the library as part 
> of the core distribution.
> 
> My apologies that these are all hand-wavy ideas, but I’m trying to paint a 
> possible alternative way to achieve your goal of more library evolution for 
> Swift without having such a formal work group that may be too heavy weight or 
> too narrowly focused.

FWIW, I don't think it much matters if they get rolled into the "core" Swift 
distribution or library... I think all that's really necessary (well, to the 

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

[Ted Kremenek via swift-evolution]

Hi Dave,

Thanks for bringing up this topic.  This has been kicked around a little, and 
we’re still exploring different models on how to extend Swift.

The server APIs work group is one operational model for the community to build 
out a new set of core libraries.  That work group was formed out of the 
observation that there were different implementations of the same thing being 
created by different Swift on server efforts, and that those different efforts 
should pool those resources together and standardize on some fundamentals.

That analogy could work here.  However, it also has possible major downsides.  
It can be heavyweight, and also artificially raise the importance of certain 
people’s library efforts over others by creating a formal work group whose 
efforts are expected to eventually be incorporated into the core Swift 
distribution.  It would also force a discussion up front of what even makes 
sense to incorporate into the core Swift distribution, which might be 
artificially constraining the exploration of the set of libraries to implement.

I need to think about your idea more, but my first reaction is that my 
preferred route is that the community builds these libraries, ideally using 
Swift Packages, and through trial and use we evaluate those libraries and then 
decide if they should be incorporated as part of the core distribution.  
There’s many factors involved in deciding if they can be incorporated into the 
core distribution, but all of those could be informed by actually building 
libraries and see them getting used.

We could also figure out a way to possibly highlight these efforts to the Swift 
community, maybe on swift-evolution or other means — but all with the 
expectation that these libraries are not *necessarily* going to be standardized 
as part of the core swift distribution.  I don’t think that’s all that bad 
either; not every library will make sense to incorporate into the core Swift 
distribution (e.g., they are highly domain specific) but still supporting their 
development would be beneficial to the community.

Note that any change going into the Swift core distribution inevitably involves 
swift-evolution and the core team.  Changes going into the core Swift 
distribution must meet a very high bar as far as implementation and design, the 
confidence we have into committing to specific APIs (especially since we’ll 
have ABI stability in Swift 5), and other factors.  Thus this will not really 
alleviate much burden on the Core team or on the community — one of the core 
goals of your proposal.  Further, incorporating all those concerns up front 
when building libraries might be counterproductive.

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.

One thing that resonates me in what you propose is about having a 
“well-organized effort” whose aim is to make these libraries feel cohesive and 
implemented well.  However, given that many of these naturally fall somewhere 
in the spectrum of responsibilities within the Standard Library and Foundation, 
I think it is self-misleading to think that the Core Team or others would not 
be involved in these efforts if the intention is to possibly incorporate these 
one day into the core Swift distribution.  There also may be other ways to 
achieve that level of cohesion in API design, such as through community 
discussion (possibly via the Swift.org  mailing 
lists/forums).  This discussion would not necessarily be the same as the path 
to “ratification” of a library into core Swift, but a step that could benefit 
many library authors (including considering ideas one day incorporated into the 
core swift).  With such a mechanism many library authors could benefit even if 
they do not intend to have the library as part of the core distribution.

My apologies that these are all hand-wavy ideas, but I’m trying to paint a 
possible alternative way to achieve your goal of more library evolution for 
Swift without having such a formal work group that may be too heavy weight or 
too narrowly focused.

Ted

> On Nov 7, 2017, at 9:54 AM, 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, 

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

[Félix Fischer via swift-evolution]

I didn’t reply to all before... um,

That’s a very good point.

Still, I’d like the rules to be as clear as possible. That only helps :)

Another point I forgot to mention, Kelvin: Jazzy (
https://github.com/realm/jazzy/blob/master/README.md) derives documentation
from the comments. We can use that in the index :)

On Tue, Nov 7, 2017 at 6:18 PM Kelvin Ma  wrote:

> On Tue, Nov 7, 2017 at 3:15 PM, Félix Fischer  wrote:
>
>> On Tue, Nov 7, 2017 at 5:24 PM Wallacy  wrote:
>>
>>> The Compatibility Suite is a good start, but I agree that something a
>>> bit more centralized has its benefits.
>>>
>>> To be perfect, Compatibility Suite and Swift Package Manager need to
>>> work "together" to offer something simple like nodejs npm and a friendly
>>> (and central) interface to not only find these projects. Something more
>>> similar to nuget too.
>>>
>>> The only thing I miss using npm and nuget is some kind of "compromise"
>>> with maintenance. And also some commitment to (avoid) rework. Several
>>> projects remake something that another does also without explaining well
>>> the differences between them.
>>>
>>> Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in
>>> project like Compatibility Suite with steroids. Not only to track those
>>> projects, but in some level help defining some standards, documentations,
>>> versioning etc. This can be done entirely within the community.
>>>
>>> Not so similar, however the gstreamer keeps a list of "base", "good",
>>> "ugly" and "bad" plugins for similar reasons.
>>>
>>> We can do something in this line of reasoning:
>>> - A central repository for projects (like Compatibility Suite)
>>> - A tool to find and add each project (like SwiftPM)
>>> - Rules for joining (like Compatibility Suite)
>>> - A classification for each repository (like gstreamer)
>>> - A good way to make each project as small and direct as possible (to
>>> take advantage of cross-module inlining / specialization)
>>> - A list of discussion (or a forum?) for people that maintain (or have
>>> an interest in maintain) projects in this "official" list.
>>>
>>
>> I like this approach much more. Feels more natural. And a forum
>> (piggybacking on the eventual Discourse perhaps). I’d only change two
>> things and extend one:
>>
>> - Instead of “central repository”, a “central index”. It makes it more
>> transparent, more distributed, and closer to the current reality.
>>
>> - Here:
>>
>>
>>> I vote for empowering SwiftPM and Compatibility Suite instead a
>>> "Non-Standard Libraries".
>>>
>>>
>> I agree with a central index, but as Kelvin says, we shouldn’t be using
>> the Compat Suite directly because of GPL issues.
>>
>> - I’d extend on the “Rules for Joining” point: they should be as clear
>> and explicit as possible, to avoid drama like the one episode that happened
>> last year on the JS repositories with that string-padding library. That
>> thing broke half of the internet for some hours, and it was all about
>> something unclear in the rules, if I remember the case correctly.
>>
>
> I think Swift is less vulnerable to that than node.js if anything because
> Swift is compiled ahead of time so someone removing their repo doesn’t
> instantly break everything else.
>
>
___
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 Tue, Nov 7, 2017 at 3:15 PM, Félix Fischer  wrote:

> On Tue, Nov 7, 2017 at 5:24 PM Wallacy  wrote:
>
>> The Compatibility Suite is a good start, but I agree that something a
>> bit more centralized has its benefits.
>>
>> To be perfect, Compatibility Suite and Swift Package Manager need to work
>> "together" to offer something simple like nodejs npm and a friendly (and
>> central) interface to not only find these projects. Something more similar
>> to nuget too.
>>
>> The only thing I miss using npm and nuget is some kind of "compromise"
>> with maintenance. And also some commitment to (avoid) rework. Several
>> projects remake something that another does also without explaining well
>> the differences between them.
>>
>> Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in
>> project like Compatibility Suite with steroids. Not only to track those
>> projects, but in some level help defining some standards, documentations,
>> versioning etc. This can be done entirely within the community.
>>
>> Not so similar, however the gstreamer keeps a list of "base", "good",
>> "ugly" and "bad" plugins for similar reasons.
>>
>> We can do something in this line of reasoning:
>> - A central repository for projects (like Compatibility Suite)
>> - A tool to find and add each project (like SwiftPM)
>> - Rules for joining (like Compatibility Suite)
>> - A classification for each repository (like gstreamer)
>> - A good way to make each project as small and direct as possible (to
>> take advantage of cross-module inlining / specialization)
>> - A list of discussion (or a forum?) for people that maintain (or have an
>> interest in maintain) projects in this "official" list.
>>
>
> I like this approach much more. Feels more natural. And a forum
> (piggybacking on the eventual Discourse perhaps). I’d only change two
> things and extend one:
>
> - Instead of “central repository”, a “central index”. It makes it more
> transparent, more distributed, and closer to the current reality.
>
> - Here:
>
>
>> I vote for empowering SwiftPM and Compatibility Suite instead a
>> "Non-Standard Libraries".
>>
>>
> I agree with a central index, but as Kelvin says, we shouldn’t be using
> the Compat Suite directly because of GPL issues.
>
> - I’d extend on the “Rules for Joining” point: they should be as clear and
> explicit as possible, to avoid drama like the one episode that happened
> last year on the JS repositories with that string-padding library. That
> thing broke half of the internet for some hours, and it was all about
> something unclear in the rules, if I remember the case correctly.
>

I think Swift is less vulnerable to that than node.js if anything because
Swift is compiled ahead of time so someone removing their repo doesn’t
instantly break everything else.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Fischer via swift-evolution]

On Tue, Nov 7, 2017 at 5:24 PM Wallacy  wrote:

> The Compatibility Suite is a good start, but I agree that something a bit
> more centralized has its benefits.
>
> To be perfect, Compatibility Suite and Swift Package Manager need to work
> "together" to offer something simple like nodejs npm and a friendly (and
> central) interface to not only find these projects. Something more similar
> to nuget too.
>
> The only thing I miss using npm and nuget is some kind of "compromise"
> with maintenance. And also some commitment to (avoid) rework. Several
> projects remake something that another does also without explaining well
> the differences between them.
>
> Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in
> project like Compatibility Suite with steroids. Not only to track those
> projects, but in some level help defining some standards, documentations,
> versioning etc. This can be done entirely within the community.
>
> Not so similar, however the gstreamer keeps a list of "base", "good",
> "ugly" and "bad" plugins for similar reasons.
>
> We can do something in this line of reasoning:
> - A central repository for projects (like Compatibility Suite)
> - A tool to find and add each project (like SwiftPM)
> - Rules for joining (like Compatibility Suite)
> - A classification for each repository (like gstreamer)
> - A good way to make each project as small and direct as possible (to take
> advantage of cross-module inlining / specialization)
> - A list of discussion (or a forum?) for people that maintain (or have an
> interest in maintain) projects in this "official" list.
>

I like this approach much more. Feels more natural. And a forum
(piggybacking on the eventual Discourse perhaps). I’d only change two
things and extend one:

- Instead of “central repository”, a “central index”. It makes it more
transparent, more distributed, and closer to the current reality.

- Here:


> I vote for empowering SwiftPM and Compatibility Suite instead a
> "Non-Standard Libraries".
>
>
I agree with a central index, but as Kelvin says, we shouldn’t be using the
Compat Suite directly because of GPL issues.

- I’d extend on the “Rules for Joining” point: they should be as clear and
explicit as possible, to avoid drama like the one episode that happened
last year on the JS repositories with that string-padding library. That
thing broke half of the internet for some hours, and it was all about
something unclear in the rules, if I remember the case correctly.

That’s all I’d add to Wallace’s list.

On another line, the licenses point brought up by Kelvin made me thought of
this:
There could be an integration in SPM or similar, that checked your license.
That way:
- It can tell you which projects you can import (that fit with your
license). That way, if you’re using the BSD license, this integration
doesn’t offer to import GPL projects because that’d make your license
inconsistent.
- It can tell you if you need to change your license or remove a package,
in order to make your license consistent again. That way, maybe you change
to GPL because you realised that the tool you wanted to use is worth it.

This would be important from the perspective of ergonomics and
(license-consistent) discovery. It’s a detail, yes. But would be very nice.


>
> Em ter, 7 de nov de 2017 às 17:19, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> escreveu:
>
>>
>>
>> On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer 
>> wrote:
>>
>>>
>>> On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma  wrote:
>>>
 On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <
 swift-evolution@swift.org> wrote:

> Hmm. I kind of like the idea, but not really. I think it has a
> fundamental flaw: centralization.
>
> You see, the StdLib can be commanded by a central authority (the core
> team) and hear the needs of the general community (through swift-evolution
> and such) because, among other things, it’s small. The StdLib solves 
> common
> and well-understood problems. Most of the solutions it provides are 
> optimal
> for all use cases.
>
> This is fundamentally different from a non-StdLib. If I understood
> your idea correctly, it would be the complement of StdLib; it will be big
> and it will attend problems that are not well-understood or whose 
> solutions
> have many differrying  approaches depending on the users’ neccessities
> (think Geometry). Therefore, a correct and complete approach would
> inevitably have to:
> - Know the needs of all the relevant user groups and balance their
> priorities.
> - Contain all the important and complementary solutions.
>
> This is very hard to achieve in a centralized system. Not impossible,
> but very resource-intensive.
>
> You can achieve something similar by letting the community grow and by
> encouraging a good 

Re: [swift-evolution] JSONEncoder: Key strategies

[David Hart via swift-evolution]

But the transformation of the string representation of keys is a feature which 
other coders/decoders could use, so it might be worth pulling it out of the 
JSONDecoder/JSONEncoder namespace and make the implementation callable. For 
example, I could imagine wanting to use a similar system with property lists 
and xml files.

How about (rough idea):

protocol KeyCodingStrategy {
func transform(codingKeys: [CodingKey]) -> CodingKey
}

struct SnakeCaseKeyDecodingStrategy {
func transform(codingKeys: [CodingKey]) -> CodingKey {
// implementation
}
}

struct SnakeCaseKeyEncodingStrategy {
func transform(codingKeys: [CodingKey]) -> CodingKey {
// implementation
}
}

class JSONDecoder {
/// The strategy to use for decoding keys. Defaults to `nil`, which is the 
default implementation.
open var keyDecodingStrategy: KeyCodingStrategy? = nil
}

class JSONEncoder {
/// The strategy to use for encoding keys. Defaults to `nil`, which is the 
default implementation.
open var keyEncodingStrategy: KeyCodingStrategy? = nil
}

var decoder = JSONDecoder()
decoder.keyDecodingStrategy = SnakeCaseKeyDecodingStrategy()
let result = try! decoder.decode(Thing.self, from: data)

David

> On 7 Nov 2017, at 18:20, Itai Ferber via swift-evolution 
>  wrote:
> 
> Hi Norio,
> 
> There are two reasons that I think this is valuable over doing something in 
> CodingKeys:
> 
> The definition you give your coding keys affects all encoding formats. JSON 
> is a format where snake_case can be relatively common, so the transformation 
> makes a lot of sense there. For other formats, like plist files or otherwise, 
> the transformation might not make as much sense. Instead of affecting all of 
> your coding keys globally, this limits it to JSON.
> More importantly, this allows you to transform keys of things which you don’t 
> necessarily own. If you’re working with types that you didn’t write (but 
> which are expected to have snake_case keys nonetheless), this allows you to 
> perform that transformation. If this were instead an annotation on CodingKeys 
> directly, you wouldn’t be able to perform it on types you don’t directly own.
> — Itai
> 
> On 6 Nov 2017, at 17:39, Norio Nomura via swift-evolution wrote:
> 
> Hi Tony,
> 
> Is it better for us to choose on `Codable` side whether `rawValue` of 
> `CodingKeys` should be generated with snake_case?
> It seems to be more consistent with the current method of setting `rawValue` 
> of `CodingKeys` on `Codable` side.
> 
> Thanks,
> --
> @norio_nomura
> 
> 2017-11-07 5:54 GMT+09:00 Tony Parker via swift-evolution 
> >:
> 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 

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[Adrian Zubarev via swift-evolution]

Same here, but I wouldn’t care much if it were gone.


Am 7. November 2017 um 21:40:56, David Hart via swift-evolution 
(swift-evolution@swift.org) schrieb:

Yeah, I use the first form constantly.

> On 6 Nov 2017, at 23:33, Slava Pestov via swift-evolution 
>  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

___
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]

The compatibility suite is not a good model because it was designed for a
completely different purpose. Its license restrictions are so that it can
be shipped in an Apple repository and it’s not really optimized for
discovery or documentation at all. Any non-standard library index must
include GPL licensed libraries, as well as have some common documentation
format. It’d be nice if the index could actually generate documentation
from source comments.

On Tue, Nov 7, 2017 at 2:24 PM, Wallacy  wrote:

> The Compatibility Suite is a good start, but I agree that something a bit
> more centralized has its benefits.
>
> To be perfect, Compatibility Suite and Swift Package Manager need to work
> "together" to offer something simple like nodejs npm and a friendly (and
> central) interface to not only find these projects. Something more similar
> to nuget too.
>
> The only thing I miss using npm and nuget is some kind of "compromise"
> with maintenance. And also some commitment to (avoid) rework. Several
> projects remake something that another does also without explaining well
> the differences between them.
>
> Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in
> project like Compatibility Suite with steroids. Not only to track those
> projects, but in some level help defining some standards, documentations,
> versioning etc. This can be done entirely within the community.
>
> Not so similar, however the gstreamer keeps a list of "base", "good",
> "ugly" and "bad" plugins for similar reasons.
>
> We can do something in this line of reasoning:
> - A central repository for projects (like Compatibility Suite)
> - A tool to find and add each project (like SwiftPM)
> - Rules for joining (like Compatibility Suite)
> - A classification for each repository (like gstreamer)
> - A good way to make each project as small and direct as possible (to take
> advantage of cross-module inlining / specialization)
> - A list of discussion (or a forum?) for people that maintain (or have an
> interest in maintain) projects in this "official" list.
>
> I vote for empowering SwiftPM and Compatibility Suite instead a
> "Non-Standard Libraries".
>
>
>
> Em ter, 7 de nov de 2017 às 17:19, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> escreveu:
>
>>
>>
>> On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer 
>> wrote:
>>
>>>
>>> On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma  wrote:
>>>
 On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <
 swift-evolution@swift.org> wrote:

> Hmm. I kind of like the idea, but not really. I think it has a
> fundamental flaw: centralization.
>
> You see, the StdLib can be commanded by a central authority (the core
> team) and hear the needs of the general community (through swift-evolution
> and such) because, among other things, it’s small. The StdLib solves 
> common
> and well-understood problems. Most of the solutions it provides are 
> optimal
> for all use cases.
>
> This is fundamentally different from a non-StdLib. If I understood
> your idea correctly, it would be the complement of StdLib; it will be big
> and it will attend problems that are not well-understood or whose 
> solutions
> have many differrying  approaches depending on the users’ neccessities
> (think Geometry). Therefore, a correct and complete approach would
> inevitably have to:
> - Know the needs of all the relevant user groups and balance their
> priorities.
> - Contain all the important and complementary solutions.
>
> This is very hard to achieve in a centralized system. Not impossible,
> but very resource-intensive.
>
> You can achieve something similar by letting the community grow and by
> encouraging a good environment. People will the build the tools they need,
> and the important voices will index the tools people use the most. That
> makes them good, as well as easily findable. It’s not perfect either, but
> it’s more efficient in my opinion.
>
> — Félix Fischer
>

 People tend to build the tools they need, but not what other people
 need.

>>>
>>> Fair point. Dog-feeding might be an issue, but not necessarily.
>>>
>>
>>> And there are many many examples from other languages of what can go
 wrong when non-standard libraries compete.

>>>
>>> Hmm. Okay, yes. But what about healthy competition? Isn’t that good as
>>> well? In which context you get bad results? Can you change the system s.t.
>>> you encourage good competition?
>>>
>>
>> i think in open source, competition is mostly beneficial when you have
>> one old monopoly that’s become lethargic and a new more energetic project
>> upends it, i.e. gcc vs clang. You get a new improved tool, and the old
>> project also gets a wakeup call, which is why you’ve seen such a big
>> improvement in recent versions 

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[David Hart via swift-evolution]

Yeah, I use the first form constantly.

> On 6 Nov 2017, at 23:33, Slava Pestov via swift-evolution 
>  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

___
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]

The Compatibility Suite is a good start, but I agree that something a bit
more centralized has its benefits.

To be perfect, Compatibility Suite and Swift Package Manager need to work
"together" to offer something simple like nodejs npm and a friendly (and
central) interface to not only find these projects. Something more similar
to nuget too.

The only thing I miss using npm and nuget is some kind of "compromise" with
maintenance. And also some commitment to (avoid) rework. Several projects
remake something that another does also without explaining well the
differences between them.

Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in
project like Compatibility Suite with steroids. Not only to track those
projects, but in some level help defining some standards, documentations,
versioning etc. This can be done entirely within the community.

Not so similar, however the gstreamer keeps a list of "base", "good",
"ugly" and "bad" plugins for similar reasons.

We can do something in this line of reasoning:
- A central repository for projects (like Compatibility Suite)
- A tool to find and add each project (like SwiftPM)
- Rules for joining (like Compatibility Suite)
- A classification for each repository (like gstreamer)
- A good way to make each project as small and direct as possible (to take
advantage of cross-module inlining / specialization)
- A list of discussion (or a forum?) for people that maintain (or have an
interest in maintain) projects in this "official" list.

I vote for empowering SwiftPM and Compatibility Suite instead a
"Non-Standard Libraries".



Em ter, 7 de nov de 2017 às 17:19, Kelvin Ma via swift-evolution <
swift-evolution@swift.org> escreveu:

>
>
> On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer  wrote:
>
>>
>> On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma  wrote:
>>
>>> On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 Hmm. I kind of like the idea, but not really. I think it has a
 fundamental flaw: centralization.

 You see, the StdLib can be commanded by a central authority (the core
 team) and hear the needs of the general community (through swift-evolution
 and such) because, among other things, it’s small. The StdLib solves common
 and well-understood problems. Most of the solutions it provides are optimal
 for all use cases.

 This is fundamentally different from a non-StdLib. If I understood your
 idea correctly, it would be the complement of StdLib; it will be big and it
 will attend problems that are not well-understood or whose solutions have
 many differrying  approaches depending on the users’ neccessities (think
 Geometry). Therefore, a correct and complete approach would inevitably have
 to:
 - Know the needs of all the relevant user groups and balance their
 priorities.
 - Contain all the important and complementary solutions.

 This is very hard to achieve in a centralized system. Not impossible,
 but very resource-intensive.

 You can achieve something similar by letting the community grow and by
 encouraging a good environment. People will the build the tools they need,
 and the important voices will index the tools people use the most. That
 makes them good, as well as easily findable. It’s not perfect either, but
 it’s more efficient in my opinion.

 — Félix Fischer

>>>
>>> People tend to build the tools they need, but not what other people
>>> need.
>>>
>>
>> Fair point. Dog-feeding might be an issue, but not necessarily.
>>
>
>> And there are many many examples from other languages of what can go
>>> wrong when non-standard libraries compete.
>>>
>>
>> Hmm. Okay, yes. But what about healthy competition? Isn’t that good as
>> well? In which context you get bad results? Can you change the system s.t.
>> you encourage good competition?
>>
>
> i think in open source, competition is mostly beneficial when you have one
> old monopoly that’s become lethargic and a new more energetic project
> upends it, i.e. gcc vs clang. You get a new improved tool, and the old
> project also gets a wakeup call, which is why you’ve seen such a big
> improvement in recent versions of gcc. Where there is no such incumbent,
> and everyone is starting from scratch, it becomes counterproductive.
>
>
>>
>> As for important voices indexing the tools people use the most, I don’t
>>> see that happening.
>>>
>>
>> This is easier than it seems. The Compatibility Suite is already an index
>> of important libraries.
>>
>> Regarding the other problems I see with this proposal: how will you
>> attend the necessities of so many diverse groups? You’d need a whole...
>> consortium, of sorts. You can’t have just a leader: no one knows the
>> context of all the users.
>>
>>
> The Compatibility Suite suffers from licensing issues which prevents a lot
> of important 

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

[Kelvin Ma via swift-evolution]

On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer  wrote:

>
> On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma  wrote:
>
>> On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hmm. I kind of like the idea, but not really. I think it has a
>>> fundamental flaw: centralization.
>>>
>>> You see, the StdLib can be commanded by a central authority (the core
>>> team) and hear the needs of the general community (through swift-evolution
>>> and such) because, among other things, it’s small. The StdLib solves common
>>> and well-understood problems. Most of the solutions it provides are optimal
>>> for all use cases.
>>>
>>> This is fundamentally different from a non-StdLib. If I understood your
>>> idea correctly, it would be the complement of StdLib; it will be big and it
>>> will attend problems that are not well-understood or whose solutions have
>>> many differrying  approaches depending on the users’ neccessities (think
>>> Geometry). Therefore, a correct and complete approach would inevitably have
>>> to:
>>> - Know the needs of all the relevant user groups and balance their
>>> priorities.
>>> - Contain all the important and complementary solutions.
>>>
>>> This is very hard to achieve in a centralized system. Not impossible,
>>> but very resource-intensive.
>>>
>>> You can achieve something similar by letting the community grow and by
>>> encouraging a good environment. People will the build the tools they need,
>>> and the important voices will index the tools people use the most. That
>>> makes them good, as well as easily findable. It’s not perfect either, but
>>> it’s more efficient in my opinion.
>>>
>>> — Félix Fischer
>>>
>>
>> People tend to build the tools they need, but not what other people need.
>>
>
> Fair point. Dog-feeding might be an issue, but not necessarily.
>
> And there are many many examples from other languages of what can go wrong
>> when non-standard libraries compete.
>>
>
> Hmm. Okay, yes. But what about healthy competition? Isn’t that good as
> well? In which context you get bad results? Can you change the system s.t.
> you encourage good competition?
>

i think in open source, competition is mostly beneficial when you have one
old monopoly that’s become lethargic and a new more energetic project
upends it, i.e. gcc vs clang. You get a new improved tool, and the old
project also gets a wakeup call, which is why you’ve seen such a big
improvement in recent versions of gcc. Where there is no such incumbent,
and everyone is starting from scratch, it becomes counterproductive.


>
> As for important voices indexing the tools people use the most, I don’t
>> see that happening.
>>
>
> This is easier than it seems. The Compatibility Suite is already an index
> of important libraries.
>
> Regarding the other problems I see with this proposal: how will you attend
> the necessities of so many diverse groups? You’d need a whole...
> consortium, of sorts. You can’t have just a leader: no one knows the
> context of all the users.
>
>
The Compatibility Suite suffers from licensing issues which prevents a lot
of important libraries from being listed in it. GPL libraries are
effectively excluded from it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

Great news — I think this will not only push Swift forward, but also empower 
more people to contribute to the ecosystem:
With the updated rules for evolution proposals, the bar to actively contribute 
to the compiler has been raised significantly; non-standard libraries on the 
other hand can be improved without knowing the details of llvm (you wouldn’t 
even need C++ ;-).

I suggest to focus on trivial data structures first, so that more advanced (and 
really non-standard libs ;-) can be build on a common basis (my favorite 
example here is the concept of a quaternion — iOS/Mac developers can encounter 
several incarnations of them without looking at third-party frameworks).
___
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 Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <
swift-evolution@swift.org> wrote:

> Hmm. I kind of like the idea, but not really. I think it has a fundamental
> flaw: centralization.
>
> You see, the StdLib can be commanded by a central authority (the core
> team) and hear the needs of the general community (through swift-evolution
> and such) because, among other things, it’s small. The StdLib solves common
> and well-understood problems. Most of the solutions it provides are optimal
> for all use cases.
>
> This is fundamentally different from a non-StdLib. If I understood your
> idea correctly, it would be the complement of StdLib; it will be big and it
> will attend problems that are not well-understood or whose solutions have
> many differrying  approaches depending on the users’ neccessities (think
> Geometry). Therefore, a correct and complete approach would inevitably have
> to:
> - Know the needs of all the relevant user groups and balance their
> priorities.
> - Contain all the important and complementary solutions.
>
> This is very hard to achieve in a centralized system. Not impossible, but
> very resource-intensive.
>
> You can achieve something similar by letting the community grow and by
> encouraging a good environment. People will the build the tools they need,
> and the important voices will index the tools people use the most. That
> makes them good, as well as easily findable. It’s not perfect either, but
> it’s more efficient in my opinion.
>
> — Félix Fischer
>

People tend to build the tools they need, but not what other people need.
And there are many many examples from other languages of what can go wrong
when non-standard libraries compete. As for important voices indexing the
tools people use the most, I don’t see that happening.
___
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]

This is something I have been pushing for for some time now and I am glad
to see some more force behind it. There are multiple prior threads about
this topic you should probably familiarize yourselves with for background:

https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20160125/007815.html

https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20170731/038401.html

Since it looks like cross-module inlining/specialization is slated for
Swift 5 I believe now is a good time to get such an effort started as this
was really the only *technical* barrier preventing such libraries from
being written in the past.


On Tue, Nov 7, 2017 at 11:54 AM, 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.
>
> *Mission Statement*
>
> 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.
>
> *Goals*
>
> The main goals of this effort would be:
>
>- Alleviate pressure on the Core Team while providing the developer
>community with functionality that normally falls under Apple's internal
>development umbrella.
>- Deliver authoritative, reliable, and regularly updated libraries
>avoiding issues faced by third-party dependencies.
>- Provide oversight, organization, and full community involvement to
>ensure its components are worthy, maintained, and passing a bar of need and
>excellence.
>
> *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.
>
> Random is currently being discussed for inclusion into the stdlib. I’m
currently developing  a modern URI type to
replace the Foundation type.


> The scope and extent of the sublibraries would be proposed and debated on
> a parallel Non-Standard Library Evolution development list.
>
> *Coordination*
>
> This effort would be fully coordinated with the Swift development team,
> respecting the team's existing commitments and responsibilities. We would
> request an Apple body to act as an official coordinator, enabling both
> oversight of this effort and to expose Apple-sourced suggestions to
> the Non-Standard community for action.
>

I love Apple but is Apple oversight really going to be beneficial enough to
warrant the additional bureaucratic overhead?


>
> *Next Steps*
>
> To proceed, we need a general community consensus that this effort is
> worth the significant overhead it would involve.
>
> We must then:
>
>- Select a project lead, who appoints technical leaders from the
>community.
>
> Yes

>
>- Recruit a core team, a small group responsible for strategic
>direction, pulled from experienced members well versed in contributing to
>Swift-dev.
>
> Yes

>
>- Establish a Non-Standard Swift Evolution process, based on the one
>that is currently followed by Swift Evolution. Following SE practices will
>guarantee a consistent and excellent language experience for those
>developers including the Non-Standard library into their projects.
>
> I disagree. Swift evolution is incredibly brittle and bureaucratic, it
only works for the stdlib because it is relatively small and most of it has
already been solidified. Any non-standard library initiative would easily
overwhelm the bandwidth of a mailing list. Project leads should have
considerably more autonomy than for the stdlib.

>
>- Build a Non-Standard Swift Evolution repository home.
>
> Yes, and might I add this is a lot more important than most people seem to
acknowledge.

>
>- Adopt a code license, based on Swift's current 

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

[Félix Fischer via swift-evolution]

Hmm. I kind of like the idea, but not really. I think it has a fundamental
flaw: centralization.

You see, the StdLib can be commanded by a central authority (the core team)
and hear the needs of the general community (through swift-evolution and
such) because, among other things, it’s small. The StdLib solves common and
well-understood problems. Most of the solutions it provides are optimal for
all use cases.

This is fundamentally different from a non-StdLib. If I understood your
idea correctly, it would be the complement of StdLib; it will be big and it
will attend problems that are not well-understood or whose solutions have
many differrying  approaches depending on the users’ neccessities (think
Geometry). Therefore, a correct and complete approach would inevitably have
to:
- Know the needs of all the relevant user groups and balance their
priorities.
- Contain all the important and complementary solutions.

This is very hard to achieve in a centralized system. Not impossible, but
very resource-intensive.

You can achieve something similar by letting the community grow and by
encouraging a good environment. People will the build the tools they need,
and the important voices will index the tools people use the most. That
makes them good, as well as easily findable. It’s not perfect either, but
it’s more efficient in my opinion.

— Félix Fischer
___
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

[Erica Sadun via swift-evolution]

You mention `.unwrap()`. This might be a good time to mention a previous 
discussion of an `Unwrappable` protocol that provides biased unwrapping and can 
extend unwrapping syntax to non-Optional types:

https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f 


-- E


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

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

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

[Dave DeLong via swift-evolution]

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.

Mission Statement

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.

Goals

The main goals of this effort would be:
Alleviate pressure on the Core Team while providing the developer community 
with functionality that normally falls under Apple's internal development 
umbrella.
Deliver authoritative, reliable, and regularly updated libraries avoiding 
issues faced by third-party dependencies.
Provide oversight, organization, and full community involvement to ensure its 
components are worthy, maintained, and passing a bar of need and excellence.
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.

Coordination

This effort would be fully coordinated with the Swift development team, 
respecting the team's existing commitments and responsibilities. We would 
request an Apple body to act as an official coordinator, enabling both 
oversight of this effort and to expose Apple-sourced suggestions to the 
Non-Standard community for action.

Next Steps

To proceed, we need a general community consensus that this effort is worth the 
significant overhead it would involve.

We must then:
Select a project lead, who appoints technical leaders from the community.
Recruit a core team, a small group responsible for strategic direction, pulled 
from experienced members well versed in contributing to Swift-dev.
Establish a Non-Standard Swift Evolution process, based on the one that is 
currently followed by Swift Evolution. Following SE practices will guarantee a 
consistent and excellent language experience for those developers including the 
Non-Standard library into their projects.
Build a Non-Standard Swift Evolution repository home.
Adopt a code license, based on Swift's current licensing.
Define the community working group rules and code of conduct.
Establish a mailing list and/or forum.
Begin the selection of target sublibraries and populating them by recruiting 
committers and contributors.
Alternative Names

Suggested names for this effort include the following.
Extended-Standard Library
Community-Standard Library
Non-Standard Library
We are not married to any of these names and welcome alternative suggestions.

Measures of Success

A successful Non-Standard Library will provide a stable and incrementally grown 
ecology of Swift frameworks that developers can depend upon with a minimum of 
turbulence and regret cycles. For that reason, the most successful content will 
be core functionality, with significant field testing prior to adoption. We 
recommend that NSSE follow a model of provisionary adoption and refinement 
before deployment to ensure any adopting code base will not be affected by 
later module changes.

Thanks,

Dave DeLong and Erica Sadun___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] JSONEncoder: Key strategies

[Itai Ferber via swift-evolution]

Hi Norio,

There are two reasons that I think this is valuable over doing something 
in `CodingKeys`:


1. The definition you give your coding keys affects all encoding 
formats. JSON is a format where snake_case can be relatively common, so 
the transformation makes a lot of sense there. For other formats, like 
plist files or otherwise, the transformation might not make as much 
sense. Instead of affecting all of your coding keys globally, this 
limits it to JSON.
2. More importantly, this allows you to transform keys of things which 
you don’t necessarily own. If you’re working with types that you 
didn’t write (but which are expected to have snake_case keys 
nonetheless), this allows you to perform that transformation. If this 
were instead an annotation on `CodingKeys` directly, you wouldn’t be 
able to perform it on types you don’t directly own.


— Itai

On 6 Nov 2017, at 17:39, Norio Nomura via swift-evolution wrote:


Hi Tony,

Is it better for us to choose on `Codable` side whether `rawValue` of
`CodingKeys` should be generated with snake_case?
It seems to be more consistent with the current method of setting
`rawValue` of `CodingKeys` on `Codable` side.

Thanks,
--
@norio_nomura

2017-11-07 5:54 GMT+09:00 Tony Parker via swift-evolution <
swift-evolution@swift.org>:


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.

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

[Cory Benfield via swift-evolution]

> On 6 Nov 2017, at 20:25, Kelvin Ma via swift-evolution 
>  wrote:
> 
> It’d be great to be able to stick an #include path and a linker flag string 
> into Package.swift instead of creating empty c modules that just include 
> system headers. right now this means you have to use a makefile (or up-arrow 
> in the terminal to get the linker flags back) to compile Swift projects that 
> depend on system libraries.

While I don’t know that I want to be able to just shove include paths and 
linker flags into Package.swift, I do think some work should be done with Swift 
projects that want to link system libraries.

Right now as Kelvin notes you end up writing a ton of copy-paste Swift packages 
that all basically have the same form: a Package.swift that lists the name of 
the .pc file, a package name derived from that, and nothing else. Maybe, if 
you’re feeling generous, a brew() and/or apt() declaration.

This is sufficiently repetitious that it would actually be possible to write a 
service that dynamically generates these on the fly: that is, you could write a 
service that links libgit2 and that builds a git repo on the fly containing 
these details and serves it to you, such that you could do git clone 
https://buildaswiftsystempackage.com/icu-uc.git 
 and would receive exactly 
this format for any .pc name.

Given that it’s so straightforward it’s probably worthwhile having SwiftPM grow 
the ability to synthesise these itself, rather than requiring users to write 
these identical modules every time.

Cory

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