Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

My inclination is to start with two broad-level categories: Evolution and User (this presumes both the evolution and user lists are moving to Discourse). To the degree that there are separate parts of evolution or user that never cross over, it would make sense to have more categories, but I

[swift-evolution] RFC: structuring forums for best use for swift-evolution

A while back a decision was reached to move from using mailing lists for swift-evolution to using a forum, specifically Discourse. At the time that decision was made, efforts had been already well committed for supporting the development of Swift 4 — including efforts supporting important

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 1, 2017, at 3:36 PM, Jean-Daniel via swift-evolution > wrote: > >> I disagree. Most of the standard library is in protocols and small generic >> wrapper structures, which are prime candidates for compile-time evaluation. >> Even if Foundation has to be

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Tue, Aug 1, 2017 at 7:38 PM, Taylor Swift wrote: > > > On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu wrote: > >> >> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> On Tue, Aug 1, 2017 at 1:51

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu wrote: > > On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>>

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 5:49 PM, David Sweeris via swift-evolution > wrote: >> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution >> wrote: >> >> A tuple can have its members initialized in piecemeal and still satisfy >>

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> Le 30 juil. 2017 à 12:23, Gor Gyolchanyan via swift-evolution > a écrit : > >> On Jul 30, 2017, at 1:03 PM, Daniel Vollmer via swift-evolution >> > wrote: >> >> Hello, >> >>> On 30. Jul 2017, at 08:52,

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution > wrote: > > A tuple can have its members initialized in piecemeal and still satisfy > deterministic initialization. The named types need to do all their > sub-objects' initializations before any

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

It's hard to say at this point since Jai is in an early state and isn't publicly available yet, but it seems to be working well on a small scale at least from the demos that have been shown. If anyone's curious, this is the video where the feature was originally demoed. It's from the very

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 1, 2017, at 9:53 AM, Daryle Walker wrote: > >> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan > > wrote: >> >>> >>> On Jul 31, 2017, at 11:23 PM, John McCall >>

Re: [swift-evolution] [Pitch] New Version of Array Proposal

>> What exactly is the problem with Sequence that makes you believe there is >> need for a more basic protocol? > > For one, the return value of map is wrong. Sequence.map returns an Array, > since a Sequence may not be a container itself. Using Array may be a minor > inconvenience for

Re: [swift-evolution] [Pitch][Bug?] Test for Anti-Conformance During Generics

Any/AnyObject are constraints for an existential container. Protocol conformances are also existential constraints, but not quite the same thing as Any/AnyObject. Rather than adding negative constraints, I think we need a richer set of more specific positive constraints.

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

> On Aug 1, 2017, at 8:50 PM, sw...@lng.la wrote: > > While we're considering compile-time execution, we should take a look at the > `#run` directive in Jon Blow's Jai programming language. It allows you to run > arbitrary code in your program at compile time and then utilize the output in >

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> What would be your compatibility and stability expectations of such APIs? Very low for the first two (or more — depending on how much attention the specific topic receives) years ;-) — but still better than nothing in the long run. Actually, some libraries (or at least parts of them) might

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

While we're considering compile-time execution, we should take a look at the `#run` directive in Jon Blow's Jai programming language. It allows you to run arbitrary code in your program at compile time and then utilize the output in your program. This page has a good summary and an example of

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < swift-evolution@swift.org> wrote: > > > On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote: > > > So, this has been discussed before on the list many times in the past. The > core

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Tue, Aug 1, 2017 at 1:44 PM, Tino Heth <2...@gmx.de> wrote: > > So, this has been discussed before on the list many times in the past. The > core team has stated that their preferred process for this is to have > individuals write their own libraries, get real-world adoption, then (as >

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 1:03 PM, Tino Heth <2...@gmx.de> wrote: > >> Sequence/Collection have other problems fitting with fixed-size arrays. >> There needs to be a new set of more basic protocols that both arrays and >> Sequence or Collection can conform to. > What exactly is the problem with

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Tue, Aug 1, 2017 at 1:20 PM, Michael Ilseman wrote: > > > On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > I’ve noticed from this and older threads that everyone agrees on what core > libraries we want, but they never

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution > wrote: > > >> So, this has been discussed before on the list many times in the past. The >> core team has stated that their preferred process for this is to have >> individuals write their own

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> So, this has been discussed before on the list many times in the past. The > core team has stated that their preferred process for this is to have > individuals write their own libraries, get real-world adoption, then (as > consensus emerges) propose their inclusion as a core library. I

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On Tue, Aug 1, 2017 at 12:21 Michael Ilseman via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > I’ve noticed from this and older threads that everyone agrees on what core > libraries we

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 10:03 AM, Tino Heth via swift-evolution > wrote: > >> But linear access isn’t an inherent canonical property of multi-dimensional >> arrays, it’s just a consequence of arrays taking a contiguous block of >> memory (which is generally treated

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Cool! When is this planned to implemented? Until then though, it’s probably a good idea to design core libraries as submodules (preferably a single file), not modules. You lose the ability to use the SPM to manage them, but you don’t have to rummage through the files and change all the access

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution > wrote: > > I’ve noticed from this and older threads that everyone agrees on what core > libraries we want, but they never actually get built. Perennial requests seem > to be > > - RNG and

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> On Aug 1, 2017, at 9:14 AM, Taylor Swift via swift-evolution > wrote: > > I’ve noticed from this and older threads that everyone agrees on what core > libraries we want, but they never actually get built. Perennial requests seem > to be > > - RNG and

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> But linear access isn’t an inherent canonical property of multi-dimensional > arrays, it’s just a consequence of arrays taking a contiguous block of memory > (which is generally treated as linear in computers). Do you know about any attempts to change this? I've seen setups of two-dimensional

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I’ve noticed from this and older threads that everyone agrees on what core libraries we want, but they never actually get built. Perennial requests seem to be - RNG and cryptography library (CryptoSwift could be a good base for this) - Generic Math library/Vector library - Basic data structures

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 3:21 AM, Tino Heth <2...@gmx.de> wrote: > >> FSAs intentionally don’t conform to Collection, because multi-dimensional >> arrays shouldn’t have to conform to a linear (by nature, hence the name >> “Sequence”) standard, at least by default. > I strongly oppose and think it

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I think the Server APIs project was pretty close to what I had in mind actually. I don’t see why more core libraries can’t be commissioned that way, things like Math and DateTime would probably draw a great deal more attention than Server APIs since they are used by more people. One thing that

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Jul 31, 2017, at 10:23 PM, Daryle Walker via swift-evolution > wrote: > > Could we do better than simple repetition? What if we define a “$$n” unit, > where “n” is a nonnegative integer. For each comma-separated item, the unit > will be replaced by increasing

Re: [swift-evolution] [Pitch] #dup -- a duplication "macro"(?)

> On Jul 31, 2017, at 10:38 PM, David Sweeris wrote: > >> On Jul 31, 2017, at 7:23 PM, Daryle Walker via swift-evolution >> > wrote: >> >> The tuple will be a bunch of “T,” but the count mechanically added

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 1, 2017, at 4:53 PM, Daryle Walker wrote: > >> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan > > wrote: >> >>> >>> On Jul 31, 2017, at 11:23 PM, John McCall >>

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Jul 31, 2017, at 4:37 PM, Gor Gyolchanyan > wrote: > >> >> On Jul 31, 2017, at 11:23 PM, John McCall > > wrote: >> >>> >>> On Jul 31, 2017, at 4:00 PM, Gor Gyolchanyan >>

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

> That's what's happened with the Server APIs Project > https://swift.org/server-apis/ > > I would like to see more of this, and math/BigNum seems like a good candidate. > > Another is a modern date/time package, standing on the shoulders of > https://jcp.org/en/jsr/detail?id=310 and similar. +

[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Even better would be something like the ‘Haskell Platform’ i.e. a curated collection of core packages that share the same ‘look’ with the stdlib. Or something similar to the boost libraries in C++. Or even something like the javax libraries. So the stdlib could stay fit, while we could still

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

Sent from my iPhone > On Jul 31, 2017, at 23:47, John McCall via swift-evolution > wrote: > > I disagree; it seems to me that a homogeneous fixed-size sequence is its own > concept, and there isn't any natural link between that concept and that of a > tuple. The

Re: [swift-evolution] Fast String Comparison From String Arrays

Hello Jon, My algorithm prioritizes time complexity and the cost is the space complexity. Time Complexity Time Complexity O(C), where C = number of matching String pyramids We usually get to compare only the very similar string pyramids together, and the comparison is usually float

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

On 1 August 2017 at 04:46, Taylor Swift via swift-evolution wrote: > I’m not saying the Swift team should devote any time or resources to writing > these things, but it’d be a huge benefit if someone were to say “okay we are > commissioning a core library that does X,

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

This is a very huge topic, but I can't fight the feeling that the final goal of the concept has mostly been ignored so far — maybe it's to exotic compared to macros: I don't know a single language that has adopted such features (except, of course, Lisp ;-) — but I guess it didn't adopt

Re: [swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

This is a very huge topic, but I can't fight the feeling that the final goal of the concept has mostly been ignored so far — maybe it's to exotic compared to macros: I don't know a single language that has adopted such features (except, of course, Lisp ;-) — but I guess it didn't adopt

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> FSAs intentionally don’t conform to Collection, because multi-dimensional > arrays shouldn’t have to conform to a linear (by nature, hence the name > “Sequence”) standard, at least by default. I strongly oppose and think it is a really bad idea: Even if arrays are modelled multi-dimensional,

Re: [swift-evolution] [Idea] Custom keywords for operators.

I understand the technical problem here, and killed my hope for "nominal" operators long time ago with fire. But if someone here uses Kotlin, they know very well how great it is to be able to infix functions of 2 parameters like they were operators: it makes code extremely clean and readable,

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

>> I expect that conforming homogeneous tuples to Collection and enabling >> subscripting is simply a matter of time. > > I disagree; it seems to me that a homogeneous fixed-size sequence is its own > concept, and there isn't any natural link between that concept and that of a > tuple. I'm

[swift-evolution] [discussion] compile-time execution and metaprogramming (was: "constexpr" for Swift 5)

As with many other threads, the "constexpr" one changed into a fixed-size array thread , so instead of fighting it, let's branch off into another topic that also almost took over. The bottom line of this discussion is to weight pros and cons of a compile-time execution feature and a

Re: [swift-evolution] Moving from Swift 2 to 4

On Jul 26, 2017, at 5:37 AM, Jonathan Hull via swift-evolution wrote: > > Is there a reason why the migration only applies to Swift 3? I have some > older files which I haven’t gotten around to upgrading until now, and Xcode > Beta says I need to migrate them with