Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

On Aug 3, 2016, at 11:11 AM, Raphael Sebbe via swift-evolution wrote: > Heard about the Swift 4 thing, so here are a few thoughts about the current > version of Swift (3). We work on a sizeable code base, with a focus on > modular code that is shared across our apps.

Re: [swift-evolution] Improved value and move semantics

On Aug 3, 2016, at 7:57 PM, Joe Groff wrote: a. We indirect automatically based on some heuristic, as an optimization. >> >> I weakly disagree with this, because it is important that we provide a >> predictable model. I’d rather the user get what they write,

Re: [swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

Here's another example use case: Auto Layout visual format strings. https://gist.github.com/jtbandes/9c1c25ee4996d2554375#file-constraintcollection-swift-L85-L87 Since only views and numeric types are supported, the generic init has to be a run-time error. Ideally it could be a compile-time

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

Using Apple Developer Forums would cause people to leave swift-evolution (a prediction). I don’t think they offer a good enough experience for quick discussions like mailing lists or Discourse do. My question is: would we gain more people than we would lose in moving over to something like

Re: [swift-evolution] [META] Gmane and Swift Evolution

I’ve submitted a pull that includes everything except for SE-0094, 0095, and 0110, which I wasn’t able to find. Saagar Jha > On Aug 3, 2016, at 11:31, Erica Sadun via swift-evolution > wrote: > > >> On Aug 2, 2016, at 9:22 AM, Ben Rimmington

Re: [swift-evolution] Improved value and move semantics

> On Aug 3, 2016, at 4:58 PM, Chris Lattner via swift-evolution > wrote: > > On Aug 3, 2016, at 6:41 AM, Matthew Johnson via swift-evolution > wrote: Then you can just slap `indirect` on a struct whose copying is too complicated

Re: [swift-evolution] MemoryLayout for a value

On Wed, Aug 3, 2016 at 8:47 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 3, 2016, at 2:43 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > Having seen the effects in the standard library and in other > > code, I'm

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

> On Aug 3, 2016, at 10:17 AM, Manav Gabhawala via swift-evolution > wrote: > > I was wondering why this would put any more of a burden on the runtime > than simple inheritance of protocols. The way this could be > implemented is to augment the ConformanceTable for

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

Exactly what I was going to say. Why not use Apple’s forum? It’s there already. It’s just a matter of using it. Some are saying things like, the core team should be focused on working on the language, etc. That’s so obvious that it shouldn’t even be said. This is a fact, but a fact that has

Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

You make some interesting points. My feedback's inline. > 1. Swift is very good for lots of stuff. My favorite is code clarity and > conciseness. Math code is great in Swift too (where I typically used Obj-C++ > previously). I can feel the potential of development going faster and code >

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> On Aug 3, 2016, at 4:11 PM, David Owens II via swift-evolution > wrote: > > But does it already surpass the limits? > >> • There is a bandwidth limit of 100k monthly page views, equivalent to >> our Standard hosting plan. >> • If you exceed our bandwidth

Re: [swift-evolution] MemoryLayout for a value

Why not just MemoryLayout.init(of instance: T), and drop the autoclosure magic altogether? The classic sizeofValue evaluated its argument, and in Foundation several uses of it actually relied on that side effect. While autoclosures are quite clever, in general I think the user expectation is that

Re: [swift-evolution] Improved value and move semantics

> On Aug 3, 2016, at 3:48 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Aug 03 2016, Matthew Johnson wrote: > >>> On Aug 2, 2016, at 4:54 PM, Dave Abrahams via swift-evolution >>> wrote: >>>

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

But does it already surpass the limits? > • There is a bandwidth limit of 100k monthly page views, equivalent to > our Standard hosting plan. > • If you exceed our bandwidth limit – which is very unlikely, unless > your project is enormous – you have two options: > •

Re: [swift-evolution] Improved value and move semantics

on Wed Aug 03 2016, Matthew Johnson wrote: >> On Aug 2, 2016, at 4:54 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Aug 02 2016, Brent Royal-Gordon wrote: >> > On Aug 2, 2016, at 12:06 PM, Dave Abrahams via

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

Keep in mind: switching to a different set of tools would create disruptions to the core team’s workflow. Context switch is expensive and perhaps hard to understand from outside. Quite a few core team members are active participants of mailing lists out side of Swift.org (yes, those indeed

[swift-evolution] MemoryLayout for a value

Having seen the effects in the standard library and in other code, I'm concerned that we may have made a mistake in removing `sizeofValue` et al without providing a replacement. In the standard library, we ended up adding an underscored API that allows

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

As I mentioned at the top of this thread, Discourse provides free hosting for community-friendly open-source projects which I suspect would include Swift. If not, that would indeed throw a

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

I’d rather the core team work on the language, stdlib and the compiler. Wouldn’t you agree? > On Aug 3, 2016, at 12:59 PM, Brandon Knope via swift-evolution > wrote: > > I wasn't expecting someone else to do it! This would need to be supported by > the core team

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

I wasn't expecting someone else to do it! This would need to be supported by the core team 100% Brandon > On Aug 3, 2016, at 3:42 PM, David Owens II wrote: > > >> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution >> wrote: >> >> I

Re: [swift-evolution] [swift-dev] [Swift 4] Organizing source stability

> On Aug 3, 2016, at 1:16 AM, Brent Royal-Gordon via swift-dev > wrote: > >> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution >> wrote: >> >> • a top-of-file "shebang"-style comment indicating the version, >>

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> On Aug 3, 2016, at 5:21 AM, Brandon Knope via swift-evolution > wrote: > > I still think it is worth doing a test to see how everyone likes it: Even if it is better, someone if going to have to either maintain the server and install of discourse _or_ pay

Re: [swift-evolution] [META] Gmane and Swift Evolution

> On Aug 2, 2016, at 9:22 AM, Ben Rimmington wrote: > > >> On 2 Aug 2016, at 16:16, Erica Sadun via swift-evolution >> wrote: >> >> Anyone willing to adopt a proposal or a group and get them updated, please >> reply in-thread and submit a

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

On Wed, Aug 3, 2016, at 11:06 AM, Felipe Cypriano via swift-evolution wrote: > On Wed, Aug 3, 2016, at 03:01, Brent Royal-Gordon via swift- > evolution wrote: 3. Native on every platform. >>> Browsers too. >> >> Safari is native, but Discourse in Safari is not by any means >> native. Any >>

[swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

Heard about the Swift 4 thing, so here are a few thoughts about the current version of Swift (3). We work on a sizeable code base, with a focus on modular code that is shared across our apps. Sorry if these things have been discussed already, just joined, and wanted to share a snapshot of our

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

On Wed, Aug 3, 2016, at 03:01, Brent Royal-Gordon via swift-evolution wrote: >>> 3. Native on every platform. >> Browsers too. > > Safari is native, but Discourse in Safari is not by any means > native. Any > attempt to define things otherwise would produce a vacuous > definition of > the term

Re: [swift-evolution] [Idea] Generic subscripts

> * Who is interested in this feature? Me definitely, everyone probably. > * Should it be severed from throwing subscripts? That depends I guess; subscripts are basically functions anyway so it didn't make a lot of sense to me that they lacked features that functions have, so if implementing

[swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

In the generics manifesto (https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md) conditional conformances via protocol extensions is under unlikely. The manifesto notes: "This is an extremely powerful feature: is allows one to map the abstractions of one domain into another

Re: [swift-evolution] [Idea] Generic subscripts

On Aug 3, 2016, at 12:25 AM, Brent Royal-Gordon via swift-evolution wrote: > I'm looking for consensus on, and a coalition for, including generic > subscripts in Phase 1 of the Swift 4 design cycle. > What I'd like to figure out at this point is: > > * Who is

Re: [swift-evolution] [Idea] Generic subscripts

+1 from me on this feature as well. It seems like a pretty obvious way in which subscripts should be like functions, but aren't yet. Would there be any need for setters and getters to have different generic parameters? I suppose today there's only one place to specify the type of the parameters,

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

If Swift team have no roadmap on those plans, any swift developers with strong in each area could kickstart and contributing libraries in Github repo. We will greatly benefit from those areas and AI. On Wed, Aug 3, 2016 at 11:10 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

A few things immediately spring to mind: • Fixed-size arrays • An optimized Matrix type • Swifty syntax for Fourier transforms • A numerical integrator (or diff-eq solver!) • BigInt capabilities The first of these (fixed-size arrays) will probably require compiler support. The rest can already

Re: [swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

> to make use of Swift more appealing and useful for science, engineering and > finance and everything else involving actually calculating things, I think it > would be a big step forward if Swift would ship with its own math/numerics > library. There are several topics that imho would benefit

Re: [swift-evolution] Improved value and move semantics

> On Aug 2, 2016, at 4:54 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Aug 02 2016, Brent Royal-Gordon wrote: > >>> On Aug 2, 2016, at 12:06 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> If it says that,

Re: [swift-evolution] [Idea] Generic subscripts

> On Aug 3, 2016, at 4:16 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 3, 2016, at 1:57 AM, Tino Heth <2...@gmx.de> wrote: >> >>> Since RangeExpression is a protocol compatible with any index type, it has >>> to have an associated type >> I

Re: [swift-evolution] [Idea] Generic subscripts

> On Aug 3, 2016, at 2:25 AM, Brent Royal-Gordon via swift-evolution > wrote: > > I'm looking for consensus on, and a coalition for, including generic > subscripts in Phase 1 of the Swift 4 design cycle. > > The Need > - > > While prototyping my

[swift-evolution] Which functionality should be covered by a native Swift math/numerics library that ships with the standard lib?

Hello Swift community, to make use of Swift more appealing and useful for science, engineering and finance and everything else involving actually calculating things, I think it would be a big step forward if Swift would ship with its own math/numerics library. Wouldn't it be great if Swift would

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

I still think it is worth doing a test to see how everyone likes it: Move swift-users (users who should see a quick benefit from because it would be more familiar) to discourse and see how that plays out. Let people test out all of the features and performance before moving the most popular

[swift-evolution] [Pre-proposal/Discussion] Padding and Smaller Integer Types?

So we have a pretty good set of integer types right now, but one issue I come into is when they don't quite fit within the padding of a type. It's not something I've ever really thought about before, since most of my background is in OOP with reference types (Java for example) and these don't

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> On 03 Aug 2016, at 12:01, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch wrote: >> >>> 1. Available on every platform. >> Browsers too. > > True. > >>> 2. Performant on every platform.

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> On Aug 2, 2016, at 10:46 PM, Jacob Bandes-Storch wrote: > >> 1. Available on every platform. > Browsers too. True. >> 2. Performant on every platform. (Discourse, for instance, struggles on >> Android.) > Browsers are heavily tuned for performance, and Discourse is a

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

I did not have the time to counter all those points but I was going to and point that Discourse has a solution for nearly all of those. I would REALLY prefer having the mailing-list part of the discussion on Discourse. > On 03 Aug 2016, at 07:46, Jacob Bandes-Storch via swift-evolution >

Re: [swift-evolution] [Idea] Generic subscripts

> On Aug 3, 2016, at 1:57 AM, Tino Heth <2...@gmx.de> wrote: > >> Since RangeExpression is a protocol compatible with any index type, it has >> to have an associated type > I haven't read all linked information, but would the situation change with > generic protocols? > Thinks like

Re: [swift-evolution] [Manifesto] Completing Generics

> On Aug 2, 2016, at 7:58 AM, Patrick Lind via swift-evolution > wrote: > > http://stackoverflow.com/questions/38619660/is-it-possible-to-pass-generic-protocols-into-a-constructor-for-proper-dependenc I *think* that the specific feature you're looking for here is

Re: [swift-evolution] [Idea] Generic subscripts

> Since RangeExpression is a protocol compatible with any index type, it has to > have an associated type I haven't read all linked information, but would the situation change with generic protocols? Thinks like "AnyGenerator" afaics would be superfluous if we had "protocol Generator", and the

Re: [swift-evolution] [Swift 4] Organizing source stability

> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > • a top-of-file "shebang"-style comment indicating the version, > something like //#swift(4), mirroring the "#if swift" syntax `import Swift 3.1`? I think this brings up two

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

We need an official poll with all the mentioned options. I believe that would make things here a little bit faster. +1 for something like discourse. --  Adrian Zubarev Sent with Airmail Am 3. August 2016 um 09:48:03, Ben Rimmington via swift-evolution (swift-evolution@swift.org) schrieb:

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

> On 1 Aug 2016, at 23:03, Brent Royal-Gordon wrote: > > I would love to have a great web archive for swift-evolution—something with a > really solid search function, good threading, and most of the other niceties > of forums. It'd even be nice to have an upvote feature. But these are all >

[swift-evolution] [Idea] Generic subscripts

I'm looking for consensus on, and a coalition for, including generic subscripts in Phase 1 of the Swift 4 design cycle. The Need - While prototyping my deferred [SE-0132][], I ran into trouble introducing `RangeExpression`, an abstraction to make the introduction of subrange