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

On Mon, Jan 16, 2017 at 12:44 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > 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

[swift-evolution] Reduce with inout

Hi, How does everyone feel about adding a second version of `reduce` to `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> A`, it would be `(inout A, Element) -> ()`. This way, we can write nice functionals algorithms, but have the benefits of inout (mutation within the

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

> My intended framing of this does not seem to be coming across in my > arguments. I am not thinking of this as a way to avoid typing ‘try!’ or > ‘try?’. This is not intended to replace any of the current uses of ‘throws’. > Rather, it is intended to replace trapping and nil-returning

[swift-evolution] [Proposal] Replace all Swift comments by end notes.

Why not replace all Swift comments by end notes at the end of each source file so as to minimize the impact of misleading/outdated comments on code comprehension? You don’t necessarily need to scroll to the end of the source file to read a referenced end note in the code since the IDE could

Re: [swift-evolution] Reduce with inout

on Mon Jan 16 2017, Chris Eidhof wrote: > Hi, > > How does everyone feel about adding a second version of `reduce` to > `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> > A`, it would be `(inout A, Element) -> ()`. This way, we can write

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

As a general rule of thumb, changes to the language should not require the use of an IDE in order to return them back to the level of usability that was had before the change. Swift is not a Mac/Xcode-only language, and even on that platform, there are a number of times where I personally find

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

> On Jan 16, 2017, at 10:55 AM, Tony Allevato wrote: > > As a general rule of thumb, changes to the language should not require the > use of an IDE in order to return them back to the level of usability that was > had before the change. Swift is not a Mac/Xcode-only

[swift-evolution] Fwd: Reduce with inout

I like it. Inicio del mensaje reenviado: > De: Dave Abrahams via swift-evolution > Fecha: 16 de enero de 2017, 5:15:23 PM GMT+1 > Para: swift-evolution@swift.org > Asunto: Re: [swift-evolution] Reduce with inout > Responder a: Dave Abrahams > >

Re: [swift-evolution] Reduce with inout

> On Jan 16, 2017, at 7:49 AM, Chris Eidhof via swift-evolution > wrote: > > Hi, > > How does everyone feel about adding a second version of `reduce` to > `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> > A`, it would be `(inout A,

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

Really glad to see this coming back :) I have a couple of questions: 1) How does Strideable relate to Arithmetic? My understanding is that Strideable allows non-numeric types to express different-type addition and subtraction, and that Arithmetic is for numeric types only (derives from

[swift-evolution] Fixing raw enum types

This idea by Karl made me branch off a new thread. 2017-01-16 21:28 GMT+03:00 Karl Wagner : It would be helpful for synthesised RawRep conformance. The > inheritance-like syntax we have now is awful - it makes people think that > RawRepresentable is some kind of magic

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

> On Jan 16, 2017, at 5:38 PM, Amir Michail via swift-evolution > wrote: > > >> On Jan 16, 2017, at 10:55 AM, Tony Allevato wrote: >> >> As a general rule of thumb, changes to the language should not require the >> use of an IDE in order

Re: [swift-evolution] Equatability for enums with associated values

> On 13 Jan 2017, at 23:02, Joe Groff via swift-evolution > wrote: > > >> On Jan 13, 2017, at 1:10 PM, Anton Zhilin via swift-evolution >> wrote: >> >> That seems pretty close to Rust’s derive. Why not invent a similar syntax in >>

[swift-evolution] SwiftPM C++ Support

Hi swift-evolution! Robert Widmann and I have been working on a Swift wrapper for LLVM (https://github.com/harlanhaskins/LLVMSwift ) and we’re lamenting the lack of C++ support in SwiftPM. Ideally, we’d be able to write C++ files that expose C APIs

Re: [swift-evolution] SwiftPM C++ Support

+ swift-build-dev On Tue, Jan 17, 2017 at 12:03 AM, Harlan Haskins via swift-evolution < swift-evolution@swift.org> wrote: > Hi swift-evolution! > > Robert Widmann and I have been working on a Swift wrapper for LLVM ( > https://github.com/harlanhaskins/LLVMSwift) and we’re lamenting the lack >

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

> On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution > wrote: > > Unless I'm mistaken, after removing division, models of SignedArithmetic > would have the mathematical properties of a ring. For every element a in ring > R, there must exist an additive

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

I really hate to bring Java up, but I really do think it got at least one thing right with its error system, namely that one subset of error (namely `RuntimeException`), wouldn't be enforced by the compiler, but could optionally be caught. Namely, all of the following would then be valid: //

Re: [swift-evolution] Reduce with inout

on Mon Jan 16 2017, Charles Srstka wrote: > On Jan 16, 2017, at 6:42 PM, Dave Abrahams via swift-evolution > wrote: >> >> >> on Mon Jan 16 2017, Charles Srstka > > wrote: >> > On Jan 16, 2017, at

Re: [swift-evolution] Pattern matching with Arrays

> On Jan 16, 2017, at 9:53 PM, Jay Abbott via swift-evolution > wrote: > > Regarding the "some-day" list (or "deferred" proposals): It has been > discussed many times before, and Chris also agreed that it would be > useful[1], but nobody seems to have made it

Re: [swift-evolution] Fixing raw enum types

Now is still the time for source breaking changes if well motivated, when dealing with key aspects of the language and we can make them objectively better then we ought to act when we can I think. +1 Sent from my iPhone > On 17 Jan 2017, at 06:11, Pranshu Goyal via swift-evolution >

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

>From what I see, talking about Fields, Rings, vector spaces etc... we're >talking about modeling the standard library upon mathematic models / axioms >(particularly algebra) and using the same terminology. Those constructions allow for a more flexible approach as one would be able to 'code

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

~Robert Widmann 2017/01/16 10:28、Amir Michail via swift-evolution のメッセージ: > Why not replace all Swift comments by end notes at the end of each source > file so as to minimize the impact of misleading/outdated comments on code > comprehension? The location of

Re: [swift-evolution] Fixing raw enum types

Definitely a +1, this clarifies intent, but enums are used a lot in swift code, and considering this is a source breaking change I'm not sure if many users of swift are going to be positive about this. On 17 January 2017 at 02:32, David Waite via swift-evolution < swift-evolution@swift.org>

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

I can't speak to the core team's motivations, but what I'm hoping for personally is a solution to this problem: Currently, there are a bunch of protocols to which integer types conform. However, they aren't very useful (not really usable) for generic programming. One example: As an exercise, I

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

Some thoughts, inline ~Robert Widmann 2017/01/14 18:18、Amir Michail via swift-evolution のメッセージ: > The code in a “code comment" must compile (not just be syntactically correct) > yet must not have any effect on the resulting executable. What is the definition of

Re: [swift-evolution] Fixing raw enum types

enum Something: RawRepresentable { } Generics? On Mon, Jan 16, 2017 at 1:51 PM Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: > This idea by Karl made me branch off a new thread. > > 2017-01-16 21:28 GMT+03:00 Karl Wagner : > > It would be helpful for

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

> On Jan 16, 2017, at 09:28, Amir Michail via swift-evolution > wrote: > > Why not replace all Swift comments by end notes at the end of each source > file so as to minimize the impact of misleading/outdated comments on code > comprehension? > > You don’t

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

> On 16 Jan 2017, at 20:26, David Sweeris via swift-evolution > wrote: > > > >> On Jan 16, 2017, at 09:28, Amir Michail via swift-evolution >> wrote: >> >> Why not replace all Swift comments by end notes at the end of each source >>

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

On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > Really glad to see this coming back :) > > I have a couple of questions: > > 1) How does Strideable relate to Arithmetic? > > My understanding is that Strideable allows non-numeric types to

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

> On Jan 16, 2017, at 8:29 PM, Karl Wagner via swift-evolution > wrote: > > >> On 16 Jan 2017, at 20:26, David Sweeris via swift-evolution >> wrote: >> >> >> >>> On Jan 16, 2017, at 09:28, Amir Michail via swift-evolution >>>

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

on Mon Jan 16 2017, Xiaodi Wu wrote: > On Mon, Jan 16, 2017 at 12:02 PM, Stephen Canon wrote: > >> On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> Unless I'm mistaken, after removing division, models of

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

On Mon, Jan 16, 2017 at 12:02 PM, Stephen Canon wrote: > On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > Unless I'm mistaken, after removing division, models of SignedArithmetic > would have the mathematical properties of a

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

> On Jan 16, 2017, at 17:16, Xiaodi Wu wrote: > > My understanding of the goal here is to model what integers can already do, > not to give them new functions. Ah, ok. Never mind then. - Dave Sweeris ___ swift-evolution mailing

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

On Mon, Jan 16, 2017 at 2:04 PM, Dave Abrahams wrote: > > on Mon Jan 16 2017, Xiaodi Wu wrote: > > > On Mon, Jan 16, 2017 at 12:02 PM, Stephen Canon > wrote: > > > >> On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution < > >>

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

> On Jan 16, 2017, at 13:40, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Jan 16, 2017 at 12:02 PM, Stephen Canon wrote: >>> On Jan 16, 2017, at 3:25 AM, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> Unless

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

I don't think this is necessary for any generic algorithms. There is already quotientAndRemainder for your use for integers, and floating point division works differently. I don't think .0 works in any case. Fundamentally, your idea would turn integers into ersatz rational numbers, but one of the

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

on Mon Jan 16 2017, Xiaodi Wu wrote: > On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > >> Really glad to see this coming back :) >> >> I have a couple of questions: >> >> 1) How does Strideable relate to

Re: [swift-evolution] Fixing raw enum types

Or perhaps paint the bikeshed enum Something<(Int32, Int32)> { … } -DW > On Jan 16, 2017, at 11:51 AM, Anton Zhilin via swift-evolution > wrote: > > This idea by Karl made me branch off a new thread. > > 2017-01-16 21:28 GMT+03:00 Karl Wagner

Re: [swift-evolution] [swift-build-dev] SwiftPM C++ Support

Hi Harlan, Can you describe more about exactly what distinct problems you are running into? Thanks! - Daniel On Mon, Jan 16, 2017 at 10:54 AM, Ankit Agarwal via swift-build-dev < swift-build-...@swift.org> wrote: > + swift-build-dev > > On Tue, Jan 17, 2017 at 12:03 AM, Harlan Haskins via

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

On Mon, Jan 16, 2017 at 3:32 PM, Karl Wagner wrote: > > On 16 Jan 2017, at 20:53, Xiaodi Wu wrote: > > On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > >> Really glad to see this coming back :) >>

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

One stray thread performing an overflowing addition can be the difference between a secure system and an insecure one. Better to take the process down. -- Callionica On Sun, Jan 15, 2017 at 10:48 PM Russ Bishop via swift-evolution < swift-evolution@swift.org> wrote: > > > I don’t think it makes

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

> On 16 Jan 2017, at 20:53, Xiaodi Wu wrote: > > On Mon, Jan 16, 2017 at 11:57 AM, Karl Wagner via swift-evolution > > wrote: > Really glad to see this coming back :) > > I have a couple of questions: > > 1)

[swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

My interpretation is that he was advocating a future where a precondition’s failure killed less than the entire process. Instead, shut down some smaller portion like a thread, actor, or container like .Net's app domains (which for those more familiar with Javascript could be loosely compared

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

On Mon, Jan 16, 2017 at 8:38 AM Amir Michail wrote: > > > On Jan 16, 2017, at 10:55 AM, Tony Allevato > wrote: > > > > As a general rule of thumb, changes to the language should not require > the use of an IDE in order to return them back to the level

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution > wrote: > > My interpretation is that he was advocating a future where a precondition’s > failure killed less than the entire process. Instead, shut down some smaller > portion like a thread, actor, or

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

on Mon Jan 16 2017, Xiaodi Wu wrote: > Strideable? I didn't think Strideable itself was going away. I'd be sad if > it did; for one, all the Unsafe*Pointers are Strideable and that has its > uses. Nobody's proposing to remove Strideable. -- -Dave

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

It would also enable the testing of fatal conditions, which would be great. -Kenny > On Jan 16, 2017, at 5:25 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution >>

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

-1 from me. I prefer at-site documentation rather than having to scroll through potentially hundreds of comments at the end of the file (each of which would then have to have additional data to provide context information that isn't needed as it currently stands. I fully understand (and agree)

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

I barely understand any of this thread, so these might be silly questions, or based on a total misunderstanding the goals here, but it seems to be about: a) clever/advanced mathsy things; b) naming things; and c) the standard library... my questions are: Do specialised clever advanced mathsy

Re: [swift-evolution] Reduce with inout

On Jan 16, 2017, at 6:42 PM, Dave Abrahams via swift-evolution wrote: > > > on Mon Jan 16 2017, Charles Srstka > wrote: > >>> On Jan 16, 2017, at 7:49 AM, Chris Eidhof via swift-evolution >>>