Re: [swift-evolution] pitch: Unified libc import (again)

On Thu, Aug 17, 2017 at 11:19 PM, Xiaodi Wu wrote: > On Thu, Aug 17, 2017 at 22:06 Taylor Swift wrote: > >> Okay I can sense this thread getting derailed so I’ll try to address your >> comments one by one. >> >> * stderr should go wherever stdin and stdout go. Since it’d be silly for >> a functi

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

On Fri, Aug 18, 2017 at 1:23 PM, Erica Sadun wrote: > I want to avoid breaking math. > it’s not that deep,,, the `for _ in 0 ..< n` loop is exactly the same thing except more verbose. In fact, that’s how your proposed ` Array.init(count:generator:)` would be implemented. But I don’t see anyone s

Re: [swift-evolution] SE-184 Improved Pointers

Should the immutable buffer pointer types also get deallocate()? On Fri, Aug 18, 2017 at 7:55 PM, Andrew Trick wrote: > > On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Implementation is here: https://github.com/a

Re: [swift-evolution] pitch: Unified libc import (again)

On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu wrote: > On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker wrote: > >> >> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift >> wrote: >> >>> I don’t think th

Re: [swift-evolution] SE-184 Improved Pointers

ould the immutable buffer pointer types also get deallocate()? > > > Both UnsafePointer and UnsafeBufferPointer should get deallocate. The Raw > API already has those methods. > > -Andy > > On Fri, Aug 18, 2017 at 7:55 PM, Andrew Trick wrote: > >> >> On A

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 6:05 PM, Andrew Trick wrote: > > On Aug 9, 2017, at 8:51 AM, Taylor Swift wrote: > > > > On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick wrote: > >> >> On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: >> >> >> On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: >> >>> >>>

Re: [swift-evolution] SE-184 Improved Pointers

, Aug 19, 2017 at 6:02 PM, Andrew Trick wrote: > > On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Implementation is here: https://github.com/apple/swift/pull/11464 > > On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift >

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 8:52 PM, Andrew Trick wrote: > >> The problem is I would expect to be able to safely call deinitialize() >> and friends after calling initialize(from:). If Element is a class type and >> initialize doesn’t fill the entire buffer range, calling deinitialize() >> will crash.

Re: [swift-evolution] SE-184 Improved Pointers

What you’re describing is basically an earlier version of the proposal which had a slightly weaker precondition (source >= destination) than yours (source == destination). That one basically ignored the Sequence methods at the expense of greater API surface area. On Sat, Aug 19, 2017 at 9:08 PM, A

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 6:16 PM, Taylor Swift wrote: > > What you’re describing is basically an earlier version of the proposal > which had a slightly weaker precondition (source >= destination) than yours > (source == destination). That one b

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 10:28 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 6:42 PM, Taylor Swift wrote: > > > > On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick wrote: > >> >> On Aug 19, 2017, at 6:16 PM, Taylor Swift wrote: >> >> What you’re describing is basically an earlier version of the p

Re: [swift-evolution] SE-184 Improved Pointers

, at: 2, from: source, count: 5) On Sun, Aug 20, 2017 at 12:12 AM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > > > On Sat, Aug 19, 2017 at 10:28 PM, Andrew Trick wrote: > >> >> On Aug 19, 2017, at 6:42 PM, Taylor Swift wrote: >> >

Re: [swift-evolution] SE-184 Improved Pointers

Sun, Aug 20, 2017 at 1:40 PM, Kelvin Ma wrote: > actually never mind that, UnsafeMutablePointer should be the only type to > not support at: arguments since offsetting them is easy with +. > > On Aug 20, 2017, at 12:12 AM, Taylor Swift via swift-evolution < > swift-evolution@sw

Re: [swift-evolution] SE-184 Improved Pointers

On Sun, Aug 20, 2017 at 10:18 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 9:12 PM, Taylor Swift wrote: > >> >> and the other methods should take both an *offset* parameter instead of >> a count parameter: >> >> initialize(from:at:) >> assign(from:at:) >> moveInitialize(from:at:) >> moveAssig

[swift-evolution] (core library) modern URL types

Okay so a few days ago there was a discussion about getting pure swift file system support into Foundation or another core library, and in my opinion, doing this requires a total overhaul of the `URL` type (which i

Re: [swift-evolution] (core library) modern URL types

st developers have to be explicit about > allowing remote resources. This makes a new URL type less necessary towards > supporting file I/O. > > Félix > > Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution < > swift-evolution@swift.org> a écrit : > > Okay so

Re: [swift-evolution] (core library) modern URL types

arate types to handle local >> and remote resources, so that at least developers have to be explicit about >> allowing remote resources. This makes a new URL type less necessary towards >> supporting file I/O. >> >> Félix >> >> Le 20 août 2017 à 21:37, Taylor

Re: [swift-evolution] SE-184 Improved Pointers

On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman wrote: > > On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: > > New draft of the proposal is up here: swift-e

Re: [swift-evolution] SE-184 Improved Pointers

ps the implementation in pr 11464 has been updated with documentation comments and changes in the latest version of the proposal On Mon, Aug 21, 2017 at 9:19 PM, Taylor Swift wrote: > > > On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman > wrote: > >>

Re: [swift-evolution] SE-184 Improved Pointers

On Mon, Aug 21, 2017 at 11:09 PM, Andrew Trick wrote: > > On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: > > New draft of the proposal is up here: swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md> > > Important changes start here >

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 22, 2017 at 2:00 AM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > > > On Mon, Aug 21, 2017 at 11:09 PM, Andrew Trick wrote: > >> >> On Aug 20, 2017, at 6:03 PM, Taylor Swift wrote: >> >> New draft of the proposal

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 22, 2017 at 2:35 AM, Andrew Trick wrote: > > On Aug 21, 2017, at 10:59 PM, Taylor Swift wrote: > > Sorry to bring this up again, but I was not able to defend the addition of >> `UnsafeMutableBufferPointer.deinitialize()`. It is incorrect for the >> typical use case and doesn't appear

Re: [swift-evolution] (core library) modern URL types

al > and remote resources, so that at least developers have to be explicit about > allowing remote resources. This makes a new URL type less necessary towards > supporting file I/O. > > Félix > > Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution < > swift-evoluti

Re: [swift-evolution] SE-184 Improved Pointers

done: https://github.com/apple/swift-evolution/pull/744 On Wed, Aug 23, 2017 at 1:56 PM, Andrew Trick wrote: > Kelvin, > > Please resubmit a clean swift-evolution PR now. I personally think this is > ready for formal review given that all feedback was positive and all issues > brought up during

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

If you ask me this thread is off topic and belongs on an Apple issue tracker or forum. XCode is just one of many editors used to edit Swift code, and it should by no means be used as a baseline for language design considering it is closed source and only available on one platform, compared to a lar

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

Where is the source for this number? XCode is not even available for Linux. And XCode’s market share is only shrinking as Swift expands more into the open source world. To make Swift depend on proprietary XCode features would nullify all of the work that has been done in the past 2 years to bring S

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

On Sat, Sep 2, 2017 at 10:03 AM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Sat, Sep 2, 2017 at 12:27 AM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > >> Hello Swift community, >> >> The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointe

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

On Sat, Sep 2, 2017 at 3:39 PM, Xiaodi Wu wrote: > On Sat, Sep 2, 2017 at 2:13 PM, Taylor Swift wrote: > >> >> >> On Sat, Sep 2, 2017 at 10:03 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> On Sat, Sep 2, 2017 at 12:27 AM, Douglas Gregor via swift-evolution < >>>

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

On Sat, Sep 2, 2017 at 7:53 PM, Andrew Trick wrote: > > On Sep 2, 2017, at 5:34 PM, Xiaodi Wu wrote: > > On Sat, Sep 2, 2017 at 4:41 PM, Andrew Trick wrote: > >> >> On Sep 2, 2017, at 2:06 PM, Taylor Swift via swift-evolution < >> swift-evolution@swift.org

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

what was the reasoning for making raw at: offset in strides and not bytes? > On Sep 3, 2017, at 10:22 PM, Andrew Trick wrote: > > >>> On Sep 3, 2017, at 8:05 PM, Xiaodi Wu wrote: >>> >>> If we use byte offset, then the at parameter in UnsafeMutableRawPointer >>> should be removed, since poin

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

we agreed to deprecate the strided at:? Note that UnsafeMutableRawBufferPointer would still need a byteOffset: argument. I’m also still not comfortable with duplicating functionality for the sake of having two names On Tue, Sep 5, 2017 at 11:31 AM, Andrew Trick wrote: > I think we’ve agreed to a

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

I’m fine with most of this On Tue, Sep 5, 2017 at 4:49 PM, Andrew Trick wrote: > > On Sep 5, 2017, at 9:53 AM, Taylor Swift wrote: > > we agreed to deprecate the strided at:? Note that > UnsafeMutableRawBufferPointer would still need a byteOffset: argument. > I’m also still not comfortable with

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

On Tue, Sep 5, 2017 at 5:16 PM, Taylor Swift wrote: > I’m fine with most of this > > On Tue, Sep 5, 2017 at 4:49 PM, Andrew Trick wrote: > >> >> On Sep 5, 2017, at 9:53 AM, Taylor Swift wrote: >> >> we agreed to deprecate the strided at:? Note that >> UnsafeMutableRawBufferPointer would still n

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

On Tue, Sep 5, 2017 at 5:36 PM, Andrew Trick wrote: > >>> In the new raw initializeMemory methods, Xiaodi and I agreed to make >>> it more clear that the offset is in terms of `self` rather than >>> `from`, and to further reduce ambiguity by forcing manual stride >>> computation and using an expl

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 Wed, Sep 6, 2017 at 12:41 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > Currently, memory is deallocated by an instance method on > UnsafeMutablePointer, deallocate(count:). Like much of the Swift pointer > API, performing this operation on a buffer pointer requires

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 6, 2017, at 4:31 PM, Joe Groff wrote: > > >> On Sep 6, 2017, at 2:28 PM, Andrew Trick wrote: >> >> On Sep 6, 2017, at 1:12 PM, Joe Groff via swift-evolution wrote: On Sep 6, 2017, at 1:06 PM, Taylor Swift wrote: > On Wed, Sep 6, 2

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 6, 2017, at 5:12 PM, Joe Groff wrote: > > >> On Sep 6, 2017, at 3:07 PM, Taylor Swift wrote: >> >> >> >>> On Sep 6, 2017, at 4:31 PM, Joe Groff wrote: >>> >>> On Sep 6, 2017, at 2:28 PM, Andrew Trick wrote: >> On Sep 6, 2017, at 1:12 PM, Joe Groff via swif

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 6, 2017, at 6:27 PM, Andrew Trick wrote: > > >> On Sep 6, 2017, at 3:42 PM, Joe Groff wrote: >> >> >>> On Sep 6, 2017, at 3:26 PM, Andrew Trick wrote: >>> >>> > On Sep 6, 2017, at 2:31 PM, Joe Groff wrote: > > > The fact that we’re using malloc and free is alr

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 6, 2017, at 6:56 PM, Andrew Trick wrote: > > >>> On Sep 6, 2017, at 4:46 PM, Taylor Swift wrote: >>> >>> A sized implementation may fail more obviously when you violate the >>> contract in the future. Not having sized deallocation is a known deficiency >>> of the C model we've bee

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 6, 2017, at 7:01 PM, Andrew Trick wrote: > > >>> On Sep 6, 2017, at 4:54 PM, Taylor Swift wrote: >>> >>> The semantics of buffer.deallocate() needs to be: free `buffer.count` bytes >>> of memory at `buffer.baseAddress`. So, that will always be the fast path! >>> Kelvin, do you agre

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 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 `copyBytes(from:)` collection method into the scope of this proposal *2*. change raw offsets to be in terms of bytes, not typed strides. This argument will be called `atBy

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 see any source for this claim in the documentation , or the source code . As far as I can tell the expected 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

not a fan of this. A lot of data structures including buffer pointers already store their capacity in a property, storing an allocation token would be redundant and waste space. It also forces allocate(capacity:) to return a tuple which is a big turn off for me. On Thu, Sep 7, 2017 at 10:56 AM, Jo

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 7, 2017 at 12:31 PM, Andrew Trick wrote: > > On Sep 7, 2017, at 8:06 AM, Taylor Swift wrote: > > I don’t see any source for this claim in the documentation > , > or the source code >

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

On Thu, Sep 7, 2017 at 1:33 PM, Jordan Rose wrote: > > > On Sep 5, 2017, at 14:50, Andrew Trick via swift-evolution < > swift-evolution@swift.org> wrote: > > We don't have a consensus, but I think the suggestion to distinguish > between single value vs. multiple semantics was good. Otherwise, > a

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 7, 2017 at 1:39 PM, Jordan Rose wrote: > > > On Sep 7, 2017, at 10:31, Andrew Trick via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Sep 7, 2017, at 8:06 AM, Taylor Swift wrote: > > I don’t see any source for this claim in the documentation >

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 7, 2017, at 3:10 PM, Joe Groff wrote: > > >> On Sep 7, 2017, at 11:57 AM, Taylor Swift wrote: >> >> >> >> On Thu, Sep 7, 2017 at 1:39 PM, Jordan Rose wrote: >>> >>> > On Sep 7, 2017, at 10:31, Andrew Trick via swift-evolution > wrote: > > > On Sep 7, 201

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

let me summarize why i think deallocate should lose the capacity parameter for now: - up to now, the capacity argument has been poorly, even misleadingly documented. this means it is unlikely that existing users of the API are using it correctly. - deallocate(capacity:) allows for opt

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

I think ClosedRange. Also there should be support for floating types. > On Sep 8, 2017, at 12:34 PM, Alejandro Alonso via swift-evolution > wrote: > > Range support is something that came up, and I think it’s a great idea as > well. My question now is do we support both `CountableRange` and >

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

I would very much like to see this implemented in pure Swift, i think it’s only a hundred lines of code to implement anyway. That way, we also have the same deterministic PRNGs across all Swift platforms. We should avoid sticking more and more stuff into Foundation if it’s not necessary for backwar

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

On Fri, Sep 8, 2017 at 8:07 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, Sep 8, 2017 at 7:50 PM, Stephen Canon wrote: > >> On Sep 8, 2017, at 8:09 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> This topic has been broached on S

Re: [swift-evolution] Figuring out what you get for free

i think in general the API docs could be organized in a more helpful way. On Fri, Sep 15, 2017 at 3:30 PM, Kyle Murray via swift-evolution < swift-evolution@swift.org> wrote: > > However, I find that I'm having trouble figuring out what I get for free > when I implement a protocol. In principle,

Re: [swift-evolution] (core library) modern URL types

RFC3986 and RFC7230) and efficiency. > > You can take a look at it here: https://github.com/my-mail-ru/swift-URI > > 2017-08-21 7:38 GMT+03:00 Taylor Swift via swift-evolution < > swift-evolution@swift.org>: > >> Okay so a few days ago there was a discussion >> &l

Re: [swift-evolution] [Discussion] Resources

I have never once felt a need to distribute a library with an icon On Fri, Sep 22, 2017 at 10:43 AM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > > On 21. Sep 2017, at 18:51, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Hi everybody! > >

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 `copyBytes(from:)` collection method into the scope of

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 Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick wrote: > > > On Sep 29, 2017, at 1:23 PM, Taylor Swift wrote: > > Instead of >> >> buf.intialize(at: i, from: source) >> >> We want to force a more obvious idiom: >> >> buf[i..> >> > The problem with subscript notation is we currently get the n a

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 5:56 PM, Dave Abrahams wrote: > > > >> On Sep 29, 2017, at 3:48 PM, Taylor Swift wrote: >> >> >> >> On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick wrote: >>> >>> > On Sep 29, 2017, at 1:23 PM, Taylor Swift wrote: > > Instead of > > buf.inti

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 Fri, Sep 29, 2017 at 6:17 PM, Andrew Trick wrote: > > > 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 wrote: > > > > On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick wrote: > >> >> >

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 `copyBytes(from:)` collection method into the scope of

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, at 10:15 PM, Taylor Swift wrote: >> >> ok

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 wrote: >> >> okay so I think so far what

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 Sep 29, 2017, at 4:03

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, 20

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 these

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

I think we should try to separate visibility from access control. In other words, the compiler should be able to see more than the user. I want to be able to write private and internal code that cannot be called explicitly in source, but can still be inlined by the compiler. Right now people are do

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

This is something I’ve been waiting for for a long time and I’m glad this is finally becoming a reality. This is a big step forward for anyone interested in seeing Swift get core “almost-stdlib” libraries. On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org

Re: [swift-evolution] [Generics] [Pitch] Dependent Types

don’t we need something like this for Fixed Size Arrays™ too? On Mon, Oct 2, 2017 at 6:23 PM, Félix Fischer via swift-evolution < swift-evolution@swift.org> wrote: > Hi swift-evolution, > > I’ve been thinking for the past months of making math libraries that could > benefit from a dependent types

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Right now @_versioned is only for internal declarations. We should have something similar for private and fileprivate declarations. I think most people use those modifiers for code organization, not binary resilience, so we would do well to make the two intents separate and explicit. On Mon, Oct 2

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

again, i should reiterate, most users aren’t compiler engineers and so most people use access modifiers as a means of code organization. being able to diagnose when a “private” symbol is being referenced from somewhere it shouldn’t be is very important; the linking and mangling details should be ha

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

On Mon, Oct 2, 2017 at 11:12 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > Maybe they've started teaching it earlier than when I went through > school... I don't think I learned it until Discrete Math, which IIRC was a > 2nd or 3rd year course at my college and only r

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

The implementation is complete and building successfully: https://github.com/apple/swift/pull/12200 On Sat, Sep 30, 2017 at 2:56 PM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > https://github.com/apple/swift-evolution/pull/750 > https://github.com/appl

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Wed, Oct 4, 2017 at 11:44 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: > > > On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: > > > > On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution < > swift-evolution@

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 5, 2017, at 12:52 AM, Slava Pestov wrote: > > > >> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution >> wrote: >> >> i’m just tryna follow along here && this is probably a dumb question, but is >> it possibl

Re: [swift-evolution] superscripts, subscripts, etc.

not to rain on anyone’s parade here but y’all are aware unicode superscripts don’t even form a complete alphabet right? This kind of syntax would really only work for positive integer literals and I don’t think making a wholesale change to the language like this is worth that. On Thu, Oct 5, 2017

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Slava Pestov wrote: > > > On Oct 4, 2017, at 11:04 PM, Taylor Swift wrote: > > > > On Oct 5, 2017, at 12:52 AM, Slava Pestov wrote: > > > > On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > i’m j

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

consistent performance penalty relative to @_inlineable > alone. > > On Thu, Oct 5, 2017 at 1:32 AM, Slava Pestov wrote: > >> >> >> On Oct 4, 2017, at 11:04 PM, Taylor Swift wrote: >> >> >> >> On Oct 5, 2017, at 12:52 AM, Slava Pestov wrote:

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

I agree with this, function signatures in Swift are long enough as it is, fitting them in 80 characters is hard enough already On Mon, Oct 9, 2017 at 11:14 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > async is a keyword where as @discardableResult is an attribute.

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

> On Oct 11, 2017, at 3:42 PM, Ben Cohen wrote: > > > >> On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution >> wrote: >> >> there is no way to allow one-sided subscripting, but disallow two-sided >> subscripting for the memory API > > One-sided subscripting is just shorthand for

Re: [swift-evolution] Making capturing semantics of local

i use a lot of local @inline(__always) functions as a sort of weird macro so this change would be hugely source breaking. Also can you even annotate a function object as force-inlineable? > On Oct 26, 2017, at 6:45 PM, Howard Lovatt via swift-evolution > wrote: > > The issues raised about loc

Re: [swift-evolution] Abstract methods

Swift architectures use much less inheritance (and class types) in general than equivalent c++ architectures. personally i have never been in a situation where i didn’t need a pure abstract method that was better declared as a protocol requirement. > On Nov 2, 2017, at 2:45 PM, C. Keith Ray via

Re: [swift-evolution] [Pitch] Angle Type

I do a lot of geometry and spherical-related work and i have never found an Angle type to be worth having. Always use radians. It’s what sin() and cos() take, it’s what graphics APIs like Cairo expect, it’s what graphics formats like SVG use. plus,, do you *really* want to be case-branching on e

Re: [swift-evolution] [Pitch] Angle Type

inlineable thing because you can’t “inline” a struct layout > >> >> also, why are radians(_:) and degrees(_:) static functions? i really only >> use static constructors for initializers that have side effects >> >>> On Sun, Jan 14, 2018 at 6:36 AM, Karl Wa

Re: [swift-evolution] [Pitch] Angle Type

> On Jan 15, 2018, at 3:40 PM, Stephen Canon wrote: > > > >>> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution >>> wrote: >>> >>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution >>> wrote: >>> >>> This could work, but you’re also giving up all the nice Numeric and

<    1   2