Re: [swift-evolution] It's the little things..

> On Dec 13, 2016, at 9:51 AM, Chris Lattner wrote: > > On Dec 12, 2016, at 6:58 PM, David Sweeris via swift-evolution > wrote: >>> On Dec 12, 2016, at 16:15, John Holdsworth via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] Add wrappers for allocWithTailElems_{n} routines

on Tue Dec 13 2016, David Sweeris wrote: >> On Dec 13, 2016, at 1:37 PM, Karl via swift-evolution >> wrote: >> >> >>> On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution >>> > > >>> wrote: >>>

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

> On Dec 11, 2016, at 2:30 AM, Tommaso Piazza via swift-evolution > wrote: > > Hello Derrick, > > I did not think of this as a bug but rather as an intentional limitation that > to me seems a little odd. > > Yes, overloads 2,3 have at least ONE operand of type

Re: [swift-evolution] Add wrappers for allocWithTailElems_{n} routines

> On Dec 13, 2016, at 1:37 PM, Karl via swift-evolution > wrote: > > >> On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution >> > wrote: >> >> >> on Tue Dec 13 2016, Alexey Komnin

Re: [swift-evolution] Add wrappers for allocWithTailElems_{n} routines

> On Dec 13, 2016, at 1:37 PM, Karl via swift-evolution > wrote: > > >> On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Dec 13 2016, Alexey Komnin wrote: >> >>> Hi

Re: [swift-evolution] Add wrappers for allocWithTailElems_{n} routines

> On 13 Dec 2016, at 20:33, Dave Abrahams via swift-evolution > wrote: > > > on Tue Dec 13 2016, Alexey Komnin > wrote: > >> Hi everyone! >> >> I really don't know whether you have discussed it

[swift-evolution] Generalised @noescape

Hi I had the need recently to mark a value-type as @noescape, but we only allow that for closure-types. I would like to propose that we allow any parameter to any function to be marked @noescape (by default, unlike closures, they would be potentially-escaping). The standard library has

Re: [swift-evolution] It's the little things..

> On Dec 12, 2016, at 4:15 PM, John Holdsworth via swift-evolution > wrote: > > As the festive season approaches I thought I’d write a brain dump > of a few things I'd hope Santa could bring in his bag for Swift 3.1. > No big ideas, just things that bug me day to day

Re: [swift-evolution] It's the little things..

On Dec 12, 2016, at 6:58 PM, David Sweeris via swift-evolution wrote: >> On Dec 12, 2016, at 16:15, John Holdsworth via swift-evolution >> wrote: >> >> I’d like to raise again the idea of optionality when referencing a key or >> calling a

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Just to share my feelings and ideas. It seems to me it would be better addressed by code review. Among other things it would start the conversation about what should be made public, what should not, and why. On the automated part, there could be tools detecting changes to the public APIs (and

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Derrick and Jean-Daniel, it's my understanding that Benjamin is proposing adding a way *to test that members are private/internal/public*, not a way to access private members in tests. If you'd like to discuss what you're describing, it's probably best to start a separate email thread. - Brian

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

Hi, I just wanted to revive this discussion and understand if this is a welcome change or not. Right now one can "fake" overload 1 inside NonEmptyArray by doing the following: ``` public struct NonEmptyArray {     private var elements: Array     private init(array: [Element]) {       

[swift-evolution] Add wrappers for allocWithTailElems_{n} routines

Hi everyone! I really don't know whether you have discussed it before. So, here is the deal. Currently, Builtin routines like allocWithTailElems_{n} not available outside of stdlib. On the other hand, those routines are widely used in implementation of containers: Array, Set, Dictionary and