Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

It won’t compile. > On Sep 30, 2017, at 7:14 PM, Taylor Swift wrote: > > what happens if two public operator declarations conflict? > > On Sat, Sep 30, 2017 at 9:10 PM, Jonathan Hull via swift-evolution > >

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

what happens if two public operator declarations conflict? On Sat, Sep 30, 2017 at 9:10 PM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > I have a technical question on this: > > Instead of parsing these into identifiers & operators, would it be > possible to parse

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

I have a technical question on this: Instead of parsing these into identifiers & operators, would it be possible to parse these into 3 categories: Identifiers, Operators, and Ambiguous? The ambiguous category would be disallowed for the moment, as you say. But since they are rarely used,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

I’m sorry, but I think we disagree on the premise. In my opinion the square brackets do exactly what we need them to do, and it’s not for the sake of anything other than consistency with the rest of the library and incidentally, reducing API complexity that I want to use them. Sent from my

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

okay, well until someone can come up with a subscript syntax that does what we need it to do, I’m inclined to view at:from: in the function parameter list as the clearest and most straightforward syntax. We shouldn’t use the square brackets for the sake of using square brackets. On Sat, Sep 30,

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

On Sat, Sep 30, 2017 at 18:59 David Sweeris wrote: > > On Sep 30, 2017, at 16:13, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I’m happy to participate in the reshaping of the proposal. It would be > nice to gather a group of people again to help

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution > wrote: > > I don’t see how it’s impractical. Quite a lot about how the library should be > optimally compiled and used depends on what you plan to do with it. If it’s > going to be installed somewhere

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Sep 30, 2017, at 16:13, Xiaodi Wu via swift-evolution > wrote: > > I’m happy to participate in the reshaping of the proposal. It would be nice > to gather a group of people again to help drive it forward. > > That said, it’s unclear to me that superscript T is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

I don't think I made any arguments that could be viewed as pointing out a problem with the slice approach, unless you take as given the idea that the slice approach should mean something novel and unprecedented. I don't see the whole/part implication that you see in the two notations, even

Re: [swift-evolution] Enums and Source Compatibility

> On 29. Sep 2017, at 00:24, Dave DeLong via swift-evolution > wrote: > > I also realize that this may be an impractical approach to solving this > problem, because it would require teaching the analyzer about built products, > with knowledge of what’s going to be

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

yeah, which is why I think the at:from: system is better than any subscript alternative. I know everyone wants to use the square brackets but it just doesn’t work very well for exactly the reasons you mentioned. On Sat, Sep 30, 2017 at 6:07 PM, Dave Abrahams wrote: > > > On

[swift-evolution] [Accepted] SE-0186 - Remove ownership keyword support in protocols

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md The review of SE-0186 “Remove ownership

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

I’m happy to participate in the reshaping of the proposal. It would be nice to gather a group of people again to help drive it forward. That said, it’s unclear to me that superscript T is clearly an operator, any more than would be superscript H (Hermitian), superscript 2, superscript 3, etc. But

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 29, 2017, at 4:03 PM, Taylor Swift wrote: > > > > On Sep 29, 2017, at 5:56 PM, Dave Abrahams > wrote: > >> >> >>> On Sep 29, 2017, at 3:48 PM, Taylor Swift >>

[swift-evolution] A path forward on rationalizing unicode identifiers and operators

The core team recently met to discuss PR609 - Refining identifier and operator symbology: https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/-refining-identifier-and-operator-symbology.md The proposal correctly observes that the partitioning of

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon > wrote: > >> On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution >> > wrote: >> >> - I’d love to see several of the most common random kinds

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

https://github.com/apple/swift-evolution/pull/750 https://github.com/apple/swift/pull/12200 On Sat, Sep 30, 2017 at 2:15 AM, Taylor Swift wrote: > > > On Thu, Sep 28, 2017 at 7:59 PM, Andrew Trick wrote: > >> >> On Sep 6, 2017, at 10:15 PM, Taylor Swift

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

this function initializeMemory(as:from:) says it will be removed in Swift 4.0. It is now Swift 4.0. can I remove it? On Sat, Sep 30, 2017 at 2:15 AM, Taylor Swift wrote: > > > On Thu, Sep 28, 2017 at 7:59 PM, Andrew Trick wrote: > >> >> On Sep 6, 2017,

Re: [swift-evolution] [Proposal] Random Unification

On Thu, Sep 28, 2017 at 12:16 PM, Félix Cloutier wrote: > > > Le 27 sept. 2017 à 17:29, Xiaodi Wu a écrit : > > What I was trying to respond to, by contrast, is the design of a hierarchy > of protocols CSPRNG : PRNG (or, in Alejandro's proposal,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

On Thu, Sep 28, 2017 at 7:59 PM, Andrew Trick wrote: > > On Sep 6, 2017, at 10:15 PM, Taylor Swift wrote: > > okay so I think so far what’s been agreed on is > > *1*. rename “Bytes” to “Memory” in the raw pointer API. Note: this brings > the