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

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

Re: [swift-evolution] JSONEncoder: Key strategies

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 othe

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

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 p

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

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

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

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 S

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

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/0078

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

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

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

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

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

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

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

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

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

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 su

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

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

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

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,

Re: [swift-evolution] JSONEncoder: Key strategies

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 pro

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

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

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

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 wor

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

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

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

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 o

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

> 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

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

> On Nov 7, 2017, at 3:12 PM, David Sweeris wrote: > >> >> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Dave, >> >> Thanks for bringing up this topic. This has been kicked around a little, >> and we’re still exploring d

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

> 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

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

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

Re: [swift-evolution] JSONEncoder: Key strategies

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 handl

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

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, down

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

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

Re: [swift-evolution] JSONEncoder: Key strategies

+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

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

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 sugges

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

• 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 easi

Re: [swift-evolution] JSONEncoder: Key strategies

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:

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

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

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

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

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

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

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

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

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

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 s

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

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 applicat

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

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

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

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() { sen

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

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 ther

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

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 {