Re: [swift-evolution] Code comments that check code validity.

Amir's idea is interesting to me. But I like Xiadi's solution with unused closure, and I don't see a reason to put more effort into this. It works well with simple and complex cases, and anyhow, for complex cases, feature switches and/or branches are already suitable, like said before. Pierre

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Stephen Canon wrote: > Responding to the thread in general here, not so much any specific email: > > “Arithmetic” at present is not a mathematically-precise concept, and > it may be a mistake to make it be one[1]; it’s a >

Re: [swift-evolution] Throws? and throws!

I’m not sure I like this specific proposal, but the idea of having the option of catching a certain class of runtime errors is appealing. I don’t think it makes sense to abort a server process (potentially dropping X threads and thousands of connections on the ground) because one stray thread

Re: [swift-evolution] Code comments that check code validity.

These (maintaining a clean codebase, using source control, branching) are good practices for solo developers as much as anyone else. > El ene. 15, 2017, a las 2:24 PM, Amir Michail via swift-evolution > escribió: > > >> On Jan 14, 2017, at 8:11 PM, Jay Abbott

Re: [swift-evolution] protocol-oriented integers (take 2)

Sent from my moss-covered three-handled family gradunza > On Jan 15, 2017, at 6:46 PM, Jacob Bandes-Storch wrote: > >> On Sun, Jan 15, 2017 at 6:13 PM, Xiaodi Wu via swift-evolution >> wrote: > >> One example: earlier, it was demonstrated that

Re: [swift-evolution] protocol-oriented integers (take 2)

Sent from my moss-covered three-handled family gradunza > On Jan 15, 2017, at 5:29 PM, Xiaodi Wu wrote: > >> On Sun, Jan 15, 2017 at 7:24 PM, Dave Abrahams wrote: >> >> on Sun Jan 15 2017, Xiaodi Wu wrote: >> >> > On Sun, Jan 15, 2017 at 6:42 PM,

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 6:13 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > One example: earlier, it was demonstrated that a genetic lerp would not > accommodate vector types. However, it _does_ work fine for any scalar (i.e. > field) type; however, with the currently

Re: [swift-evolution] protocol-oriented integers (take 2)

Responding to the thread in general here, not so much any specific email: “Arithmetic” at present is not a mathematically-precise concept, and it may be a mistake to make it be one[1]; it’s a mathematically-slightly-fuzzy “number” protocol. FWIW, if I had to pick a mathematical object to pin it

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 15, 2017, at 19:24, Dave Abrahams wrote: > > >> on Sun Jan 15 2017, Xiaodi Wu wrote: >> >>> On Sun, Jan 15, 2017 at 6:42 PM, David Sweeris wrote: >>> >>> >>> >>> >>> >>> On Jan 15, 2017, at 18:02, Xiaodi Wu wrote:

Re: [swift-evolution] protocol-oriented integers (take 2)

One example: earlier, it was demonstrated that a genetic lerp would not accommodate vector types. However, it _does_ work fine for any scalar (i.e. field) type; however, with the currently proposed integer protocols, one would constrain it to Arithmetic types, yet the algorithm would be bogus for

Re: [swift-evolution] Generic Subscripts

> On Jan 15, 2017, at 8:32 PM, Dave Abrahams wrote: > > > on Sun Jan 15 2017, John McCall wrote: > >>> On Jan 15, 2017, at 7:22 PM, Dave Abrahams wrote: >>> on Sun Jan 15 2017, John McCall wrote: >>> > On Jan 14, 2017, at 6:41 PM, Dave

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Xiaodi Wu wrote: > On Sun, Jan 15, 2017 at 3:27 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Sun Jan 15 2017, Xiaodi Wu wrote: >> >> > There _may_ be value in recognizing the distinction between rings and

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 6:42 PM, David Sweeris wrote: > > > > Sent from my iPhone > On Jan 15, 2017, at 18:02, Xiaodi Wu wrote: > > "Mathematically correct" integers behave just like Int in that there is > not a multiplicative inverse. What we're trying

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Jacob Bandes-Storch wrote: > On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu wrote: > >> On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> [ proposal link:

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Xiaodi Wu wrote: > On Sun, Jan 15, 2017 at 6:42 PM, David Sweeris wrote: > >> >> >> >> >> On Jan 15, 2017, at 18:02, Xiaodi Wu wrote: >> >> "Mathematically correct" integers behave just like Int in that there is >> not a

Re: [swift-evolution] Generic Subscripts

on Sun Jan 15 2017, John McCall wrote: >> On Jan 15, 2017, at 7:22 PM, Dave Abrahams wrote: >> on Sun Jan 15 2017, John McCall wrote: >> On Jan 14, 2017, at 6:41 PM, Dave Abrahams via swift-evolution > wrote: on Fri Jan 13

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 7:24 PM, Dave Abrahams wrote: > > on Sun Jan 15 2017, Xiaodi Wu wrote: > > > On Sun, Jan 15, 2017 at 6:42 PM, David Sweeris > wrote: > > > >> > >> > >> > >> > >> On Jan 15, 2017, at 18:02, Xiaodi Wu wrote:

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Jacob Bandes-Storch wrote: > [ proposal link: https://gist.github.com/moiseev/ > 62ffe3c91b66866fdebf6f3fcc7cad8c ] > > On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> Responding to both Jacob and Xiaodi here;

Re: [swift-evolution] Generic Subscripts

> On Jan 15, 2017, at 7:22 PM, Dave Abrahams wrote: > on Sun Jan 15 2017, John McCall wrote: > >>> On Jan 14, 2017, at 6:41 PM, Dave Abrahams via swift-evolution >>> wrote: >>> on Fri Jan 13 2017, John McCall wrote:

Re: [swift-evolution] protocol-oriented integers (take 2)

Sent from my iPhone > On Jan 15, 2017, at 18:02, Xiaodi Wu wrote: > > "Mathematically correct" integers behave just like Int in that there is not a > multiplicative inverse. What we're trying to do here is to determine how much > of what we know about mathematics is

Re: [swift-evolution] Generic Subscripts

on Sun Jan 15 2017, Jacob Bandes-Storch wrote: > On Sat, Jan 14, 2017 at 3:41 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Fri Jan 13 2017, John McCall wrote: >> >> > I'm also not sure we'd ever want the element type to be

Re: [swift-evolution] Generic Subscripts

on Sun Jan 15 2017, John McCall wrote: >> On Jan 14, 2017, at 6:41 PM, Dave Abrahams via swift-evolution >> wrote: >> on Fri Jan 13 2017, John McCall wrote: >> >>> I'm also not sure we'd ever want the element type to be inferred from >>>

Re: [swift-evolution] Generic Subscripts

> On Jan 13, 2017, at 9:33 PM, Brent Royal-Gordon > wrote: >> On Jan 13, 2017, at 9:50 AM, John McCall via swift-evolution >> wrote: >> >> I'm also not sure we'd ever want the element type to be inferred from >> context like this. Generic

Re: [swift-evolution] protocol-oriented integers (take 2)

"Mathematically correct" integers behave just like Int in that there is not a multiplicative inverse. What we're trying to do here is to determine how much of what we know about mathematics is usefully modeled in the standard library. The answer is not zero, because there is more than just

Re: [swift-evolution] Generic Subscripts

> On Jan 14, 2017, at 6:41 PM, Dave Abrahams via swift-evolution > wrote: > on Fri Jan 13 2017, John McCall wrote: > >> I'm also not sure we'd ever want the element type to be inferred from >> context like this. Generic subscripts as I see

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 15, 2017, at 17:19, Jacob Bandes-Storch via swift-evolution > wrote: > > >> On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu wrote: >>> On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution >>>

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 2:42 PM, Xiaodi Wu wrote: > On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > >> [ proposal link: https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f >> 3fcc7cad8c ] >> >> >> On Sat,

Re: [swift-evolution] Pattern matching with Arrays

On Tue, Jan 3, 2017 at 10:10 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > On Dec 22, 2016, at 7:43 PM, Robert Widmann > wrote: > > Do you think there’s room for a more general Pattern Synonyms-like >

Re: [swift-evolution] Throws? and throws!

On Sun, Jan 15, 2017 at 3:12 PM, Haravikk wrote: > > On 12 Jan 2017, at 23:35, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> I

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 3:29 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote: > [ proposal link: https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f > 3fcc7cad8c ] > > > On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution < >

Re: [swift-evolution] Generic Subscripts

On Sat, Jan 14, 2017 at 3:41 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jan 13 2017, John McCall wrote: > > > I'm also not sure we'd ever want the element type to be inferred from > > context like this. Generic subscripts as I

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 3:27 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sun Jan 15 2017, Xiaodi Wu wrote: > > > There _may_ be value in recognizing the distinction between rings and > > fields, perhaps? Just as the FP protocols

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Xiaodi Wu wrote: > There _may_ be value in recognizing the distinction between rings and > fields, perhaps? Just as the FP protocols make room for people to implement > their own decimal FP types, and just as you're trying to make Arithmetic >

Re: [swift-evolution] protocol-oriented integers (take 2)

[ proposal link: https://gist.github.com/moiseev/ 62ffe3c91b66866fdebf6f3fcc7cad8c ] On Sat, Jan 14, 2017 at 4:55 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > Responding to both Jacob and Xiaodi here; thanks very much for your > feedback! > > on Sat Jan 14 2017,

Re: [swift-evolution] Throws? and throws!

> On 12 Jan 2017, at 23:35, Xiaodi Wu via swift-evolution > > wrote: > > On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution > > wrote: > I really like

Re: [swift-evolution] protocol-oriented integers (take 2)

You're quite right. Since the multiplicative inverse of any integer other than 1 and -1 is not itself an integer, there isn't much one can do... On Sun, Jan 15, 2017 at 08:41 Dave Abrahams wrote: > > > on Sun Jan 15 2017, Xiaodi Wu wrote: > > > > > Given that Arithmetic

Re: [swift-evolution] protocol-oriented integers (take 2)

There _may_ be value in recognizing the distinction between rings and fields, perhaps? Just as the FP protocols make room for people to implement their own decimal FP types, and just as you're trying to make Arithmetic accommodate complex numbers, the distinction would allow someone to write

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Rob Mayoff wrote: > On Sat, Jan 14, 2017 at 7:41 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> Oh... you mean that word(at:) itself would be linear, and thus >> algorithms that iterate the words linearly would be O(N^2)... yuck. >> > >

[swift-evolution] Make nested functions less order-dependent.

I like to suggest relaxing ordering restriction of nested functions. In short, just allow nested functions to be defined below its call site. ("Use of local variable ‘b’ before its declaration.” error) Here’s more explanation. In Swift, we can define nested functions. func a() {

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sat, Jan 14, 2017 at 7:41 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > Oh... you mean that word(at:) itself would be linear, and thus > algorithms that iterate the words linearly would be O(N^2)... yuck. > Couldn't you fix this by replacing `func word(at n:

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Anton Zhilin wrote: > What about taking a mathematical approach to numbers? > > protocol Group : Equatable { > static var zero: Self { get } > static func + (Self, Self) -> Self > static func += (inout Self, Self) > static func -

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, David Sweeris wrote: >> On Jan 14, 2017, at 18:55, Dave Abrahams via swift-evolution >> wrote: >> >> >> Responding to both Jacob and Xiaodi here; thanks very much for your >> feedback! > >> >>> on Sat Jan 14 2017, Xiaodi Wu

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Xiaodi Wu wrote: > Given that Arithmetic also provides for multiplication and division, might > it be wise then also to have .multiplicativeIdentity (or .one)? I'm always wary of adding requirements that don't have a demonstrated use-case in a generic algorithm. What

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sun Jan 15 2017, Nate Cook wrote: > Excited to see this getting closer! > >> On Jan 14, 2017, at 7:41 PM, Dave Abrahams via swift-evolution >> wrote: >> >> on Sat Jan 14 2017, Benjamin Spratling > >

Re: [swift-evolution] Code comments that check code validity.

> On Jan 14, 2017, at 8:11 PM, Jay Abbott wrote: > > I think this would be an anti-feature , here are some reasons why: > > • If it is code you wrote as an idea for how something might be > implemented in the future, then it should be manually tweaked/validated >

Re: [swift-evolution] protocol-oriented integers (take 2)

What about taking a mathematical approach to numbers? protocol Group : Equatable { static var zero: Self { get } static func + (Self, Self) -> Self static func += (inout Self, Self) static func - (Self, Self) -> Self static func -= (inout Self, Self) static prefix func -

Re: [swift-evolution] protocol-oriented integers (take 2)

on Sat Jan 14 2017, Dave Abrahams wrote: > That said, the ability to interpret integer literals as an arbitrary > Arithmetic isn't used anywhere in the standard library, so I'd like to > consider undoing >

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 14, 2017, at 18:55, Dave Abrahams via swift-evolution > wrote: > > > Responding to both Jacob and Xiaodi here; thanks very much for your > feedback! > >> on Sat Jan 14 2017, Xiaodi Wu wrote: >> >> On Sat, Jan 14, 2017 at 1:32

Re: [swift-evolution] protocol-oriented integers (take 2)

> On Jan 15, 2017, at 03:20, Xiaodi Wu via swift-evolution > wrote: > > Given that Arithmetic also provides for multiplication and division, might it > be wise then also to have .multiplicativeIdentity (or .one)? > >> On Sun, Jan 15, 2017 at 02:47 Dave Abrahams via

Re: [swift-evolution] Generic Subscripts

I agree with Dave. To me, building in a limit so that the return type can't be inferred seems arbitrary. On Sun, Jan 15, 2017 at 12:41 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Fri Jan 13 2017, John McCall wrote: > > > I'm also

Re: [swift-evolution] protocol-oriented integers (take 2)

Given that Arithmetic also provides for multiplication and division, might it be wise then also to have .multiplicativeIdentity (or .one)? On Sun, Jan 15, 2017 at 02:47 Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sat Jan 14 2017, Dave Abrahams

Re: [swift-evolution] protocol-oriented integers (take 2)

On Sun, Jan 15, 2017 at 2:00 AM, Nate Cook via swift-evolution < swift-evolution@swift.org> wrote: > > Link: https://github.com/natecook1000/swift/blob/nc- > bigint/test/Prototypes/BigInt.swift > > This is just a proof of concept BigInt implementation—there's not much in > the way of optimization