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: >>> >>> I’d like to raise again the idea of optionality when referencing a key or >>>

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 >>> mailto:swift-evolution@swift.org>> > >>> wrote: >>> >>> >>> on Tue Dec 13 2016, Alexey Komnin >>

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 NonEmptyArray so when > declar

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> >> on Tue Dec 13 2016, Alexey Komnin > > wrote: >> >>> Hi everyone! >>>

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 everyone! >>> >>> I really don't know whether you have discussed it before. So, here

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 before. So, here is the >> deal. >> >> Currently, Builtin rou

[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 several

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

If not using '?' at arbitrary positions, but instead applying '?' to the function call, it looks like it's possible to enable OK syntax by defining a custom operator (at least for unnamed args): let result = fn<-?(a, b) Here: - fn is a function that has two non-optional parameters - a and b are o

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

on Tue Dec 13 2016, Alexey Komnin wrote: > 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 imp

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 and would be > backward sou

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 function could be possible using a ? i.e instead of >>

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

Howdy, If my immediate goal were to verify private member values at intermediate steps in some process, which is the concept under consideration in the article you provided, I could access their values with a Mirror. That's not my immediate goal. My immediate goal is to falsify that the prope

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]) {        self.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 other