Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

On Thu, Aug 3, 2017 at 11:03 PM, Gwendal Roué via swift-evolution < swift-evolution@swift.org> wrote: > > > Le 3 août 2017 à 19:10, Itai Ferber a écrit : > > > > I just mentioned this in my other email, but to point out here: the > reason this works in your case is because you

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

> Le 3 août 2017 à 17:44, Taylor Swift via swift-evolution > a écrit : > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution > > wrote: >>> >>> The root cause, of course, is that the VLAs

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

For what it’s worth, I’d be happy with just subscripts on tuples and some form of shorthand for their size. Maybe (Float ... 5) or something like that. That would obviate the need for an attribute too. On Thu, Aug 3, 2017 at 11:48 PM, Karl Wagner wrote: > > Actually, if

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> Le 3 août 2017 à 19:10, Itai Ferber a écrit : > > I just mentioned this in my other email, but to point out here: the reason > this works in your case is because you adopt these methods as static funcs > and can reasonably rely on subclasses of NSData, NSNumber, NSString,

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

> Actually, if you do a lot of graphics programming like I do, the memory > layout is very, very important. Swift may not care about layout, but many > APIs that it interacts with do. > Sure; I’m well-aware of how important it can be to decide on an appropriate memory layout. I’m very much

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

On Thu, Aug 3, 2017 at 11:17 PM, Karl Wagner wrote: > > On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> The

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

> On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution > wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution > > wrote: >>> >>> The root cause, of course, is that the

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

Where do constant Arrays currently live? I hope the answer is on the stack, since their size doesn’t change. > On Aug 3, 2017, at 8:44 PM, Taylor Swift via swift-evolution > wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution >

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

>> >> The root cause, of course, is that the VLAs require new stack allocations >> each time, and the stack is only deallocated as one lump when the frame ends. > > That is true of alloca(), but not of VLAs. VLAs are freed when they go out > of scope. > Learned something today. Anyway, if

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

A math library should include vectorized operations as part of its vector type support; i currently use this snippet to cover that. Even though they are evaluated as scalars right now, if simd/sse support ever comes to Linux it’ll

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

On Thu, Aug 3, 2017 at 7:12 PM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution < > swift-evolution@swift.org> wrote: > > On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution < > swift-evolution@swift.org>

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

On Thu, Aug 3, 2017 at 7:17 PM, Karl Wagner wrote: > > On 3. Aug 2017, at 20:52, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > In an effort to get this thread back on track, I tried implementing > cos(_:) in pure generic Swift code, with the

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

> On 3. Aug 2017, at 20:52, Taylor Swift via swift-evolution > wrote: > > In an effort to get this thread back on track, I tried implementing cos(_:) > in pure generic Swift code, with the BinaryFloatingPoint protocol. It > deviates from the _cos(_:) intrinsic by

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

> On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution > wrote: > >> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution >> > wrote: >> >> It’s important to remember that computers are

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

When moving to a forum, the problem becomes a thread splintering to an overwhelming tree. I'd prefer to see a single primary thread (as in the mailing lists) with breakout threads for working groups. These could be built either around already identified areas (see manifestos) or future

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

Interesting figures. I will not try to discuss the generics, inlineable, etc. there are certainly good observations and comments to make here, but most people in this list know certainly more about it than I do. I just want to point out that IMO a core math library for swift should comply with

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

In an effort to get this thread back on track, I tried implementing cos(_:) in pure generic Swift code, with the BinaryFloatingPoint protocol. It deviates from the _cos(_:) intrinsic by no more than 5.26362703423544e-11. Adding more terms to the approximation only has a small penalty to the

Re: [swift-evolution] Inconsistencies related to prepositions

And likewise! I hope we can continue to work together to make Swift more dynamic, expressive, and useful in the months and years going forward :). Best, Austin On Thu, Aug 3, 2017 at 10:33 AM, Goffredo Marocchi wrote: > > Thank you for the long reply, I do agree that I could

Re: [swift-evolution] Inconsistencies related to prepositions

Thank you for the long reply, I do agree that I could have been more constructive and what I said could have been more on point with the thread at hand and better argued. I do like a complete and well written rebuttal, chance for me to learn from it :). On Thu, Aug 3, 2017 at 5:14 PM, Austin

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

I just mentioned this in my other email, but to point out here: the reason this works in your case is because you adopt these methods as static funcs and can reasonably rely on subclasses of NSData, NSNumber, NSString, etc. to do the right thing because of work done behind the scenes in the

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Thanks for putting these thoughts together, Jordan! Some additional comments inline. > On Aug 2, 2017, at 5:08 PM, Jordan Rose wrote: > > David Hart recently asked on Twitter > if there was a good > way to add

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

On Thu, Aug 3, 2017 at 3:21 AM, Tino Heth <2...@gmx.de> wrote: > > You're welcome to join me in my endeavor to create a math library. I'd bet > Karoly feels the same way about his project. > > See, exactly this is the big problem we are facing here — probably not in > your specific case, but in

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

I don’t think we should be designing interfaces based off of what pure mathematicians write. Scientists aren’t the only people who use sin(x). It’s better to go with the “common sense” behavior than the esoteric academic notation. And for the record, I think Matrix.map(sin(_:)) is the best and

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

There’s also a PureSwift organization of GitHub that has several Swift PM packages built specifically with Linux support in mind https://github.com/PureSwift It looks like it’s along the lines of SwiftBreezy, but it hasn’t died out…yet. At the same time, this may

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

Hi! I hope I sent this email correctly and it entered the RFC thread started by Ted. My pitch: what about timeline of thread as a category? Like this: - Short term: for current release of Swift, aka 4.1 after 4.0 is released. - Mid term: for next release of Swift, aka 4.0 now, because 3.x is the

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Aug 2, 2017, at 10:48 PM, David Hart wrote: > > Somewhat related: I have a similar problem in a project where I need two > different Codable conformances for a type: one for coding/decoding from/to > JSON, and another one for coding/decoding from/to a database row. The

Re: [swift-evolution] Inconsistencies related to prepositions

On Thu, Aug 3, 2017 at 8:13 AM, Goffredo Marocchi wrote: > Because what is the current idiomatic Swift of today may not be the Swift > of tomorrow if people are allowed to keep shaping it as it gets used in the > real world. Ideas can be imported from other languages and

[swift-evolution] Fwd: Inconsistencies related to prepositions

-- Forwarded message -- From: Goffredo Marocchi Date: Thu, Aug 3, 2017 at 4:13 PM Subject: Re: [swift-evolution] Inconsistencies related to prepositions To: Austin Zheng Because what is the current idiomatic Swift of today may not be

Re: [swift-evolution] Inconsistencies related to prepositions

If you want to use Objective-C you're free to use Objective-C, or more generally any of the wonderful languages that choose a different tradeoff regarding convenience over expressiveness. Otherwise, I'm not really sure what productive forward movement bringing up complaints about a fundamental

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

> I’m not saying that tuple member names are “true integers” (although, with > Reflection…). I understood that, semantically, the reason we refer to > elements .0, .1 and .2 of a tuple because that’s their name, not necessarily > because its their position in the tuple. My point is that for a

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

> On 3. Aug 2017, at 07:26, John McCall wrote: > >> On Aug 3, 2017, at 12:45 AM, Daryle Walker > > wrote: >>> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution >>>

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

> Honestly, a lot of this still applies. I would like to see fixed-sized > arrays in the language eventually, but they are not going to become a > priority, because there's a lot of other stuff that is more important to work > on. I guess it all depends on the the future focus of the

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

Hi Daryle, I think we agree a lot on the importance of fixed-size arrays, but have a different opinion on which aspect is the most valuable… (so we now only have to agree that mine is better ;-) ;-) My motivation for FSA is safety and convenience: I want to iterate over C arrays in a

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

> On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution > wrote: > > It’s important to remember that computers are mathematical machines, and some > functions which are implemented in hardware on essentially every platform > (like sin/cos/etc) are definitely

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

> On Aug 2, 2017, at 6:37 PM, Nicolas Fezans via swift-evolution > wrote: > > I am of course not talking about a syntax sugar to call a sin or cos > function, but rather to manipulate other objects such as N-dimensional > matrices, defining maths functions that can

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> Le 3 août 2017 à 02:09, Jordan Rose via swift-evolution > a écrit : > > P.S. There's a reason why Decodable uses an initializer instead of a > factory-like method on the type but I can't remember what it is right now. I > think it's something to do with having

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

> Well that there is a rather defeatist attitude. If you are correct that > Apple-funded development is the only way to get core libraries built (and > maintained), and Apple has expressed they have no intention of doing so, then > we are all pretty much fd. I don't think Apple-funded

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Wrapper structs FTW. I think it's a lovely pattern that's super Swifty and really should be advertised more for solving these kinds of problems. Language-level features could also be useful for making that more usable, and the discussion about "strong" typealiases seems oriented in that

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

> You're welcome to join me in my endeavor to create a math library. I'd bet > Karoly feels the same way about his project. See, exactly this is the big problem we are facing here — probably not in your specific case, but in general: It's not very appealing for most people to contribute to a

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

> The other point I'd make here is that I definitely think the core team is > right about encouraging any "entire API spec" for a math library to be based > on implementation experience from actually writing a math library that has > seen good adoption. Essentially, what they're saying is that

Re: [swift-evolution] Inconsistencies related to prepositions

Sent from my iPhone > On 3 Aug 2017, at 04:39, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 2, 2017, at 10:49 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> Brent had a draft proposal to revise the names of collection

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On 3 Aug 2017, at 08:00, Slava Pestov wrote: > > >> On Aug 2, 2017, at 10:48 PM, David Hart > > wrote: >> >> Somewhat related: I have a similar problem in a project where I need two >> different Codable conformances for a

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Sent from my iPhone > On 3 Aug 2017, at 01:09, Jordan Rose via swift-evolution > wrote: > > > 'required' initializers are like methods: they may require dynamic dispatch. > That means that they get an entry in the class's dynamic dispatch table, > commonly known