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

[Taylor Swift via swift-evolution]

> 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 
>>> FloatingPoint conformances when you use this,, all of a sudden adding two 
>>> angles together isn’t let γ = α + β, it’s γ = Angle.radians(α.radians + 
>>> β.radians). just no. at the risk of blowing up the scope of this idea, 
>>> dedicated Angle types also begs for generic trigonometric functions like 
>>> Angle.sin(_:) and Angle.cos(_:). i proposed that a while back and even 
>>> tried implementing it but fast trig evaluation doesn’t genericize well 
>>> since it relies a lot on rsqrt-style magic constants
>> 
>> You could add those conformances back, if you wanted. Most low-level trig 
>> code will quickly escape the wrapper once it starts using the values. Mostly 
>> I use it as a currency type and for converting untyped angles. I think it’s 
>> a great example of Swift’s zero-cost abstractions - we added semantic 
>> meaning (this value isn’t just a number with a specific bit representation, 
>> it’s a number which represents a specific kind of quantity), and 
>> encapsulated some useful functionality, and we don't lose any performance.
> 
> And in fact you probably don’t want that conformance. It makes sense 
> dimensionally to add two angles. It doesn’t (generally) make as much sense to 
> multiply them, or to take the square root of an angle. I would expect an 
> angle type to provide + and - but probably not * and / and most of the other 
> floating-point operations.
> 
> – Steve

steradians?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

> On Jan 15, 2018, at 3:30 PM, Karl Wagner  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 
>> FloatingPoint conformances when you use this,, all of a sudden adding two 
>> angles together isn’t let γ = α + β, it’s γ = Angle.radians(α.radians + 
>> β.radians). just no. at the risk of blowing up the scope of this idea, 
>> dedicated Angle types also begs for generic trigonometric functions like 
>> Angle.sin(_:) and Angle.cos(_:). i proposed that a while back and even tried 
>> implementing it but fast trig evaluation doesn’t genericize well since it 
>> relies a lot on rsqrt-style magic constants
> 
> You could add those conformances back, if you wanted. Most low-level trig 
> code will quickly escape the wrapper once it starts using the values. Mostly 
> I use it as a currency type and for converting untyped angles. I think it’s a 
> great example of Swift’s zero-cost abstractions - we added semantic meaning 
> (this value isn’t just a number with a specific bit representation, it’s a 
> number which represents a specific kind of quantity), and encapsulated some 
> useful functionality, and we don't lose any performance.
> 
> I have a couple of these, such as Distance and Time (wraps a 
> TimeInterval). This allows me to write algorithms like:
> 
> public func point(_ distance: Distance, along bearing: 
> Angle) -> Geo.Point
> 
> And use it like this:
> 
> let nextPlace = thisPlace.point(.kilometers(42), along: .degrees(45))
> 
> Or this:
> 
> let nextPlace = thisPlace.point(.miles(500), along: .radians(.pi/2))
> 
> And so my algorithm actually becomes quite difficult to use incorrectly. 
> Also, that’s why I use static constructors; similar to how lots of OptionSet 
> types are implemented, doing it this way lets you use an enum-like syntax to 
> create values, which fits Angle’s intended use as a parameter/return type.
> 
> I’m not saying this should be part of the standard library (this isn’t my 
> pitch), I’m just saying these kind of wrappers are useful when creating good 
> APIs. I think somebody was dismissing the idea of an Angle type in general 
> before.
> 
> - Karl

i thought the whole thing with resiliency barriers is that these kinds of 
abstractions are *not* zero cost anymore, accessing a member of an imported 
struct is always going to be through an indirect getter and setter. && this 
doesn’t get fixed by slava’s 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 Wagner  wrote:
>>> 
>>> 
>>>> On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution 
>>>>  wrote:
>>>> 
>>>> 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 
>>>> every angle value? that really adds up when you’re converting 100,000s of 
>>>> lat-long pairs to cartesian.
>>> 
>>> You can do it without case-branching. I too have an Angle type; this is 
>>> what I use:
>>> 
>>> public struct Angle {
>>>   public var radians: T
>>>   public var degrees: T {
>>> return (radians / .pi) * 180
>>>   }
>>> 
>>>   public static func radians(_ rads: T) -> Angle {
>>> return Angle(radians: rads)
>>>   }
>>>   public static func degrees(_ degs: T) -> Angle {
>>> return Angle(radians: (degs / 180) * .pi)
>>>   }
>>> }
>>> 
>>> If you ask for “radians” (like most low-level trig code will), you just get 
>>> the stored property. The conversion “overhead” is only done at construction 
>>> time, so it makes a convenient parameter/return value.
>>> 
>>> - Karl
>>> 
>>>> 
>>>>> On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution 
>>>>>  wrote:
>>>>> 
>>>>> An Angle type already exists in Foundation; see Measurement. 
>>>>> You could add some convenience methods in an extension pretty easily.
>>>>> 
>>>>> import Foundation
>>>>>

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

[Taylor Swift via swift-evolution]

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 every angle 
value? that really adds up when you’re converting 100,000s of lat-long pairs to 
cartesian.

> On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution 
>  wrote:
> 
> An Angle type already exists in Foundation; see Measurement. You 
> could add some convenience methods in an extension pretty easily.
> 
> import Foundation
> 
> typealias Angle = Measurement
> 
> extension Measurement where UnitType == UnitAngle {
> var sine: Double {
> let radians = self.converted(to: .radians).value
> return sin(radians)
> }
> 
> static var threeQuarterTurn: Angle {
> return Angle(value: 0.75, unit: .revolutions)
> }
> }
> 
> let x = Angle.threeQuarterTurn
> x.sine // -1
> 
> -BJ
> 
> 
>> On Jan 13, 2018, at 9:31 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> I would like to see a full Geometry implementation but I don't think it 
>> should be part of the standard library.
>> 
>> I've kicked around some ideas here: 
>> 
>> * https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b
>> * https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721
>> 
>> and
>> 
>> * https://github.com/erica/SwiftGeometry
>> 
>>> On Jan 13, 2018, at 7:49 PM, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> Hi Evolution,
>>> 
>>> I would really like to see Swift gain an Angle type in the standard 
>>> library.  Every time I have to deal with an angle in an api, I have to go 
>>> figure out the conventions for that call.  Is it in degrees? Is it in 
>>> radians?  What if it is in radians, but I want to think about it in degrees?
>>> 
>>> I ended up writing an Angle type for my own code a few years back, and I 
>>> have to say it is really wonderful.  It has greatly simplified my graphics 
>>> work.  It takes a lot of mental load off of my brain when dealing with 
>>> Angles.
>>> 
>>> I can of course initialize it either as degrees or radians (or 
>>> revolutions), but I can also just say things like ‘.threeQuarterTurn’, and 
>>> then I can get the value back out in whatever format I like.  There are 
>>> also useful additions that let me normalize the angle to different ranges 
>>> and which let me snap to the nearest multiple of an angle. Both of these 
>>> are enormously useful for user facing features.  I can also do math on 
>>> angles in a way that makes geometric sense for angles.  It is also really 
>>> useful for interacting with CGVectors in intelligent ways.
>>> 
>>> Using Doubles or CGFloats to represent angles everywhere is just 
>>> semantically wrong IMHO, and it stops us from adding all of these 
>>> angle-specific niceties.
>>> 
>>> Happy to provide code if there is interest…
>>> 
>>> Thanks,
>>> Jon
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Swift via swift-evolution]

Hi Jordan,

Thanks for your thoughtful reply. Comments inline...

Sent from my iPad

> On Jan 4, 2018, at 5:37 PM, Jordan Rose  wrote:
> 
> Hi, Dave. You're right, all these points are worth addressing. I'm going to 
> go in sections.
> 
>> This whole “unexpected case” thing is only a problem when you’re linking 
>> libraries that are external to/shipped independently of your app. Right now, 
>> the *only* case where this might exist is Swift on the server. We *might* 
>> run in to this in the future once the ABI stabilizes and we have the Swift 
>> libraries shipping as part of iOS/macOS/Linux. Other than this, unexpected 
>> enum cases won’t really be a problem developers have to deal with.
> 
> 
> I wish this were the case, but it is not. Regardless of what we do for Swift 
> enums, we are in dire need of a fix for C enums. Today, if a C enum doesn't 
> have one of the expected values, the behavior is undefined in the C sense (as 
> in, type-unsafe, memory-unsafe, may invoke functions that shouldn't be 
> invoked, may not invoke functions that should be invoked, etc).

That’s a fair point, and one I had forgotten about. Thanks for reminding me.

> Obviously that's an unacceptable state of affairs; even without this proposal 
> we would fix it so that the program will deterministically trap instead. This 
> isn't perfect because it results in a (tiny) performance and code size hit 
> compared to C, but it's better than leaving such a massive hole in Swift's 
> safety story.
> 
> The trouble is that many enums—maybe even most enums—in the Apple SDK really 
> are expected to grow new cases, and the Apple API authors rely on this. Many 
> of those—probably most of them—are the ones that Brent Royal-Gordon described 
> as "opaque inputs", like UIViewAnimationTransition, which you're unlikely to 
> switch over but which the compiler should handle correctly if you do. Then 
> there are the murkier ones like SKPaymentTransactionState.
> 
> I'm going to come dangerously close to criticizing Apple and say I have a lot 
> of sympathy for third-party developers in the SKPaymentTransactionState case.

This isn’t criticism.


You’re acknowledging the complexities that exist when writing software, from 
the point-of-view of someone who has no insight in to the intricacies and 
challenges faced by the StoreKit team. Our takeaway from this is that no one 
writes perfect code.


😉

> As Karl Wagner said, there wasn't really any way an existing app could handle 
> that case well, even if they had written an 'unknown case' handler. So what 
> could the StoreKit folks have done instead?

Well, the converse is also true: what reasonable logic exists that an app 
developer could do to handle a new transaction state for which they’re 
unprepared? The only sensical thing would be to abort the transaction, 
apologize to the user, and quickly release an update to your app.

> They can't tell themselves whether your app supports the new case, other than 
> the heavy-handed "check what SDK they compiled against" that ignores the 
> possibility of embedded binary frameworks.

To be fair, a “linked on or after” check isn’t that heavy-handed. It’s a single 
if-statement. Yes, they become unwieldy if you’ve got them *everywhere* in your 
library code, which is why I brought up the point earlier that I’d really love 
to see more in the way of facilitating this sort of link-dependent behavior 
that apps are expecting.

The software-level solution is to make everything require a configuration 
object (as you allude to below), but a lower-level solution would (hopefully) 
be even nicer.

> So maybe they should have added a property "supportsDeferredState" or 
> something that would have to be set before the new state was returned.
> 
> (I'll pause to say I don't know what consideration went into this API and I'm 
> going to avoid looking it up to avoid perjury. This is all hypothetical, for 
> the next API that needs to add a case.)
> 
> Let's say we go with that, a property that controls whether the new case is 
> ever passed to third-party code. Now the new case exists, and new code needs 
> to switch over it. At the same time, old code needs to continue working. The 
> new enum case exists, and so even if it shouldn't escape into old code that 
> doesn't know how to handle it, the behavior needs to be defined if it does. 
> Furthermore, the old code needs to continue working without source changes, 
> because updating to a new SDK must not break existing code. (It can introduce 
> new warnings, but even that is something that should be considered carefully.)
> 
> So: this proposal is designed to handle the use cases both for Swift library 
> authors to come and for C APIs today, and in particular Apple's Objective-C 
> SDKs and how they've evolved historically.
> 
> 
> There's another really interesting point in your message, which Karl, Drew 
> Crawford, and others also touched on.
> 
>> Teaching the compiler/checker/whatever about the

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

[Swift via swift-evolution]

I agree with this. The only app-based use case I can think of for a full-range 
random value would be to construct a unique temporary file name. But that’s 
easily replaced with UUID().uuidString or mkstemp() (or whatever it’s called). 

Dave

Sent from my iPhone

> On Nov 17, 2017, at 9:10 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> 
>> Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution 
>>  a écrit :
>> 
>> If we go back to your example, you never call FixedWidthInteger.random 
>> either, you call range.random. Does this mean integer types shouldn’t have 
>> .random? No, because it means get a random number from it’s internal range 
>> (alias to (min ... max).random). I think we can all agree that 
>> Integer.random is a nicer api than making a range of its bounds. The same 
>> goes for Date.random and Color.random.
>> 
>> - Alejandro
> 
> Hello,
> 
> I'm not random expert, but it has never happened in my developer life 
> (backend & frontend app developer) that I have used a pure random value from 
> the full domain of the random type. In this life:
> 
> - Int.random is _always_ followed by % modulo. Unless the better 
> arc4random_uniform(max) is used.
> - Color.random is _never_ used, because random colors look bad.
> - Date.random is _never_ used, because time is a physical unit, and random 
> points in time do not match any physical use case.
> 
> This does not mean that random values from the full domain are useless. Of 
> course not: math apps, fuzzers, etc. need them.
> 
> Yet a range-based API would be much welcomed by regular app developers. And 
> also Array.randomElement(), Array.shuffled(), etc, because there are plenty 
> naive and bad algorithms for those simple tasks.
> 
> Gwendal Roué
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

[Swift via swift-evolution]

> On Nov 3, 2017, at 9:59 PM, Chris Lattner  wrote:
> 
> 
>> On Nov 3, 2017, at 8:40 AM, Dave DeLong via swift-evolution 
>>  wrote:
>> 
>> That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap.
>> 
>> Chris has mentioned in interviews that such a system is "a big feature 
>> that’s open-ended and requires a huge design process” which makes 
>> off-the-table for Swift 5, and (I’m guessing) unlikely for Swift 6 too.
>> 
>> Personally I’d like to be able to better debug my apps in Swift 4.1 rather 
>> than waiting another 2 or 3 years for a magical macro system to somehow 
>> solve this.
> 
> You’re assuming somehow that this is an “easy” feature.  I haven’t seen a 
> concrete proposal, but I don’t see how adding hidden options to operators 
> compose into the existing system.
> 
> -Chris

It’s possible I missed something, but my attempt at implementing it only 
touched 3 files. One was the actual implementation, another was adapting the 
diagnostics messages, and the third was the tests. 

I’m still new to building swift myself, but the tests all passed...

https://github.com/davedelong/swift/commit/c65c634a59b63add0dc9df1ac8803e9d70bfa697

As for a formal proposal, I’ll hopefully have some time this weekend to put 
that together. 

Can you expound some more on what you mean by hidden options to operators not 
composing into the existing system? I’m not sure I follow. 

Dave

> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Abstract methods

[Taylor Swift via swift-evolution]

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 swift-evolution 
>  wrote:
> 
> How many "subclass must override" assertions or comments in base class 
> methods do we need to see, to want to add "abstract" to the Swift language? 
> 5? 50? 500?
> 
> It's a not uncommon idiom in Objective-C.
> 
> I'm about to port a substantial amount of C++ code to swift, and compiler 
> help to enforce abstract classes would be very useful.
> 
> 
> --
> C. Keith Ray
> Senior Software Engineer / Trainer / Agile Coach
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 local capture by local (inner) functions are valid, 
> likewise the discussion about the @nonescaping annotation are also valid.
> 
> Rather than expand local function syntax why not deprecate local functions 
> completely and add the @nonescaping annotation to local closures following 
> the argument syntax, e.g. the running example:
> 
> 
> class A {
> func foo() {
> let local: @nonescaping () -> void = {
> bar() // Capture of self does not need to be explicit in the 
> closure because it is non-escaping.
> }
> local()
> }
> func bar() { ... }
> }
> 
> This is a simpler and more powerful solution (I think others have pretty much 
> suggested the same thing in this forum but have not explicitly said get rid 
> of local functions).
> 
>   -- Howard.
> 
>> On 27 October 2017 at 08:16, Mike Kluev via swift-evolution 
>>  wrote:
>>> On 26 October 2017 at 20:24, David Hart  wrote:
>> 
>>> I don’t see how this makes any sense or be possible:
>>> 
>>> * It doesn’t make sense for me because local is not a member function of A.
>>> * It would cause ambiguity when trying to call another member function with 
>>> the same name as the local function.
>> 
>> in the escaping contexts, "self." is currently required before the instance 
>> members (**). 
>> the idea is to require it before some local functions as well, recursively 
>> analysing what these local functions do (at the compile time).
>> 
>> /* local */ foo() {
>> bar()
>> variable = 1
>> }
>> 
>> ...
>> self.foo()
>> 
>> // self is required because the compiler knows what's inside, and if it were 
>> to put the content inline that would be:
>> 
>> // inlining foo pseudo code:
>>  self.bar()
>>  self.variable = 1
>> 
>> hence the compiler can figure out that in this case "self" is required 
>> before foo()
>> 
>> on the other hand:
>> 
>> /* local */ poo() {
>> print("doesnt not capture anything")
>> }
>> 
>> here, if compiler were to use poo in the escaping context it would not 
>> require "self." before it.
>> 
>> this decision (whether to require "self." on not) can be on the use side.
>> 
>> (**) FTM, the normal instance methods that do not capture anything may as 
>> well not require "self." before them in escaping contexts:
>> 
>> /* non local */ baz() {
>> print("doesn't capture anything")
>> }
>> 
>> Mike
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

> 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 “from here to the end” (or from 
> the start to/through here). If a one-sided subscript is just shorthand for a 
> two-sided subscript there cannot be a circumstance where one is allowed but 
> not the other. This kind of rule should be consistent throughout the library.

You are entirely correct which is why i’m not comfortable with this syntax.

> 
> If a “from:” argument, similarly, means “write from here up to the end” (and 
> no further, it’s reasonable to assume, if we’re talking about collections) 
> then x.foo(from: i) is similar to saying x[i…].foo(), which in turn is 
> similar to saying x[5.. 

from: in the buffer pointer API refers to the source buffer which contains a 
`count` property. it’s analogous to the count: argument in the plain pointer 
API.

> Do you feel like a “from:” argument avoids implying there is a specific end 
> point to the operation? That is, it might not get as far as x.endIndex if it 
> runs out of stuff to write. Whereas x[i.. “this will definitively replace the entire range from i to the end”?
> 
> (with x[i…].foo() living in an unpleasant grey-area)
> 

pretty much. We only want one "count" number floating around here so the 
behavior is easy to think about, and since the source buffer already contains a 
count we want the syntax to avoid implying a second quantity that might 
contradict `source.count` as much as possible.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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. This pitch
> does not include any advantages over the current form. In fact this will
> rather harm the readbility because you no longer can nicely put the
> annotation above the function and it won’t play well with other keywords
> like throws, rethrows and async.
>
> @discardableResult
> funx foo() { /* ... */  }
>
> So -1 for this pitch.
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 9. Oktober 2017 um 18:02:14, Dave DeLong via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
>> Oooo, I really like this.
>>
>> It also brings up an interesting point on the whole async discussion.
>> Doesn’t the async apply to the *return value* and not the other stuff?
>>
>> IE instead of:
>>
>> async func getBool() → Bool
>>
>> It could be:
>>
>> func getBool() → async Bool
>>
>> Dave
>>
>> On Oct 9, 2017, at 9:58 AM, Fil Ipe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I find it extremely cumbersome to have to precede a function declaration
>> with such an extensive annotation such as @discardableResult
>>
>> Now that so many functions do need this annotation to be there, our code
>> became so ugly.
>>
>> Besides, having this annotation precede the function declaration kind of
>> reminds me of C rather than Swift. Since in C the function declarations
>> started by the type of the return value.
>>
>> I, therefore, think it would be much softer on the eye, and much more
>> precise in intent, to instead precede the result of a func with a simpler
>> and shorter @discardable annotation
>>
>> So it would be:
>>
>> func() -> @discardable Bool { }
>>
>> Rather than:
>>
>> @discardableResult func() -> Bool { }
>>
>> It could be even better if someone could perhaps find a shorter word that
>> is a synonym for the word "discardable", that would be as explicit in
>> intent as the word "discardable" is in such context, yet be written with
>> fewer characters.
>>
>> Swift regards,
>> Filipe Sá.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

why is runtime dispatch even necessary? Why can’t the client just call the
specialized version directly?

On Thu, Oct 5, 2017 at 2:01 AM, Slava Pestov  wrote:

> Oh right. @_specialize modifies the original entry point to do runtime
> dispatch among the possible specializations. So the overhead comes from the
> unnecessary checks. I guess ideally we would have two versions of
> @_specialize, one adds the runtime dispatch whereas the other one just
> publishes static specializations which can be deserialized and used as
> needed.
>
> Since @_specialize is not an officially supported attribute though, I
> would suggest punting this discussion until someone decides to push through
> an evolution proposal for it. For all intents and purposes, @inlinable is a
> superset of @_specialized because it defers the specialization decisions to
> the client.
>
> Slava
>
>
> On Oct 4, 2017, at 11:47 PM, Taylor Swift  wrote:
>
> See the thread
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038571.html>
> from july over generic trig functions, where @_specialize() + @_inlineable
> had a small but 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:
>>
>>
>>
>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> i’m just tryna follow along here && this is probably a dumb question, but
>> is it possible for a generic function to be emitted as a set of specialized
>> functions into the client, but not inlined everywhere? It can be the case
>> where a large generic function gets slowed down by the large number of
>> generic operations inside it but it doesn’t make sense for it to be inlined
>> completely.
>>
>>
>> This is already possible. The optimizer doesn’t have to inline an
>> @_inlineable function at its call site; it can emit a call to a specialized
>> version instead.
>>
>> Slava
>>
>>
>> Is there a reason using @_specialize() and @_inlineable together is
>> slower than using @_inlineable by itself?
>>
>>
>> By specialization, I mean the optimizer pass which takes a function body
>> and substitutes generic parameters with statically-known types.
>>
>> I’m not sure what your question means though. Adding a @_specialize
>> attribute should never make anything slower. Rather it makes the optimizer
>> eagerly emit specializations of a function in the defining module. You can
>> think of @_specialize and @inlinable as mostly mutually exclusive; either
>> you publish the complete function body for clients to optimize as they
>> please, or you publish a fixed set of specializations.
>>
>> You might prefer the latter for secrecy (serialized SIL is much closer to
>> source code than machine code), but the the former enables more general
>> optimizations.
>>
>> Slava
>>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

See the thread
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038571.html>
from july over generic trig functions, where @_specialize() + @_inlineable
had a small but 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:
>
>
>
> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> i’m just tryna follow along here && this is probably a dumb question, but
> is it possible for a generic function to be emitted as a set of specialized
> functions into the client, but not inlined everywhere? It can be the case
> where a large generic function gets slowed down by the large number of
> generic operations inside it but it doesn’t make sense for it to be inlined
> completely.
>
>
> This is already possible. The optimizer doesn’t have to inline an
> @_inlineable function at its call site; it can emit a call to a specialized
> version instead.
>
> Slava
>
>
> Is there a reason using @_specialize() and @_inlineable together is slower
> than using @_inlineable by itself?
>
>
> By specialization, I mean the optimizer pass which takes a function body
> and substitutes generic parameters with statically-known types.
>
> I’m not sure what your question means though. Adding a @_specialize
> attribute should never make anything slower. Rather it makes the optimizer
> eagerly emit specializations of a function in the defining module. You can
> think of @_specialize and @inlinable as mostly mutually exclusive; either
> you publish the complete function body for clients to optimize as they
> please, or you publish a fixed set of specializations.
>
> You might prefer the latter for secrecy (serialized SIL is much closer to
> source code than machine code), but the the former enables more general
> optimizations.
>
> Slava
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 at 1:19 AM, Swift via swift-evolution <
swift-evolution@swift.org> wrote:

> Going a little further...
>
> It’s not hard to imagine a situation where the *order* of a trailing
> annotation matters. Ie, that X²₃ is a different thing from X₃². (X squared
> sub 3 ≠ X sub 3 squared)
>
> So i think you’d want an array of trailing annotations and an array of
> leading annotations, where an annotation is either a .superscript(U) or a
> .subscript(V). That way you’d be able to preserve the (potentially)
> relevant order.
>
> Dave
>
> Sent from my iPhone
>
> On Oct 5, 2017, at 12:04 AM, John Payne via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Chris Lattner wrote:
>
> Just FWIW, IMO, these make sense as operators specifically because they
> are commonly used by math people as operations that transform the thing
> they are attached to.  Superscript 2 is a function that squares its
> operand.  That said, perhaps there are other uses that I’m not aware of
> which get in the way of the utilitarian interpretation.
>
>
> But there are SO MANY uses for superscripts, subscripts, and other such
> annotations, and they are all context specific, just in math, without
> getting into chemistry, physics, statistics, and so forth.
>
> They’re really more like methods on the object to which they’re attached,
> or the combination of a method and an argument.
>
>
> I agree.
>
> Wouldn’t classing them as identifiers lend itself better to this?
>
>
> No, making them an operator is better for this usecase.
>
> You want:
>
> x²  to parse as “superscript2(x)” - not as an identifier “xsuperscript2”
> which is distinct from x.
>
> -Chris
>
>
> I’m not competent to evaluate the implications of that, but let me just
> pass along what makes sense to me.  For all I know it may be a restatement
> in different words, or a higher level view which your approach enables, or
> I may just have no grasp at all of what’s involved.
>
> For brevity I’ll refer to superscripts, subscripts, etc. as annotations.
>
> An object may have more than one annotation, as with chemical elements
> which are usually presented at least with both their atomic number and
> atomic weight.  Moreover, in some circumstances it might not be possible to
> evaluate the significance of any single annotation without taking one or
> more others into account, so it might be important to present them
> together, as in a struct or a collection.
>
> Taking them singly, their significance is three part: 1) the type of the
> object, 2) the position of the annotation, and 3) the value of the
> annotation.
>
> I would parse x² as x.trailingSuperscript(2), or better yet…
>
> where X is the type of x, X.annotations would be a struct, similar to the
> following
>
> struct annotations {
> leadingSuperscript: T?
> leadingSubscript: U?
> triailingSuperscript: V?
> trailingSubscript: W?
> }
>
> Taking this approach, x² would parse as x.annotations.trailingSuperscript
> = 2, and would fail if X made no allowance for trailingSuperscripts.
>
> Annotation values are frequently variables, xⁿ for example, and this is
> the main reason it seems reasonable to me to class the value as anything
> permitted by the type associated with an annotation in that position for
> the overall type in question.
>
> I’ll read any replies with interest, but I don’t think I'll have anything
> more to say on this subject myself.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Swift via swift-evolution]

Going a little further...

It’s not hard to imagine a situation where the order of a trailing annotation 
matters. Ie, that X²₃ is a different thing from X₃². (X squared sub 3 ≠ X sub 3 
squared)

So i think you’d want an array of trailing annotations and an array of leading 
annotations, where an annotation is either a .superscript(U) or a 
.subscript(V). That way you’d be able to preserve the (potentially) relevant 
order. 

Dave

Sent from my iPhone

> On Oct 5, 2017, at 12:04 AM, John Payne via swift-evolution 
>  wrote:
> 
> 
>>> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution 
>>>  wrote:
>>> 
>>> Chris Lattner wrote:
>>> 
 Just FWIW, IMO, these make sense as operators specifically because they 
 are commonly used by math people as operations that transform the thing 
 they are attached to.  Superscript 2 is a function that squares its 
 operand.  That said, perhaps there are other uses that I’m not aware of 
 which get in the way of the utilitarian interpretation.
>>> 
>>> But there are SO MANY uses for superscripts, subscripts, and other such 
>>> annotations, and they are all context specific, just in math, without 
>>> getting into chemistry, physics, statistics, and so forth.
>>> 
>>> They’re really more like methods on the object to which they’re attached, 
>>> or the combination of a method and an argument.  
>> 
>> I agree.
>> 
>>> Wouldn’t classing them as identifiers lend itself better to this?
>> 
>> No, making them an operator is better for this usecase.
>> 
>> You want:
>> 
>> x²  to parse as “superscript2(x)” - not as an identifier “xsuperscript2” 
>> which is distinct from x.
>> 
>> -Chris
> 
> I’m not competent to evaluate the implications of that, but let me just pass 
> along what makes sense to me.  For all I know it may be a restatement in 
> different words, or a higher level view which your approach enables, or I may 
> just have no grasp at all of what’s involved.
> 
> For brevity I’ll refer to superscripts, subscripts, etc. as annotations.
> 
> An object may have more than one annotation, as with chemical elements which 
> are usually presented at least with both their atomic number and atomic 
> weight.  Moreover, in some circumstances it might not be possible to evaluate 
> the significance of any single annotation without taking one or more others 
> into account, so it might be important to present them together, as in a 
> struct or a collection.
> 
> Taking them singly, their significance is three part: 1) the type of the 
> object, 2) the position of the annotation, and 3) the value of the annotation.
> 
> I would parse x² as x.trailingSuperscript(2), or better yet…
> 
> where X is the type of x, X.annotations would be a struct, similar to the 
> following
> 
> struct annotations {
> leadingSuperscript: T?
> leadingSubscript: U?
> triailingSuperscript: V?
> trailingSubscript: W?
> }
> 
> Taking this approach, x² would parse as x.annotations.trailingSuperscript = 
> 2, and would fail if X made no allowance for trailingSuperscripts.
> 
> Annotation values are frequently variables, xⁿ for example, and this is the 
> main reason it seems reasonable to me to class the value as anything 
> permitted by the type associated with an annotation in that position for the 
> overall type in question.
> 
> I’ll read any replies with interest, but I don’t think I'll have anything 
> more to say on this subject myself.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

> 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 possible for a generic function to be emitted as a set of specialized 
>> functions into the client, but not inlined everywhere? It can be the case 
>> where a large generic function gets slowed down by the large number of 
>> generic operations inside it but it doesn’t make sense for it to be inlined 
>> completely.
> 
> This is already possible. The optimizer doesn’t have to inline an 
> @_inlineable function at its call site; it can emit a call to a specialized 
> version instead.
> 
> Slava

Is there a reason using @_specialize() and @_inlineable together is slower than 
using @_inlineable by itself?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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@swift.org> wrote:
>
> We have discussed adding a "versioned @inlinable" variant that preserves
> the public entry point for older clients, while making the declaration
> inlinable for newer clients. This will likely be a separate proposal and
> discussion.
>
> 5) It eliminates this complexity.
>
>
> It wouldn't avoid the complexity, because we want the "non-ABI,
> always-emit-into-client" behavior for the standard library. For the
> soon-to-be-ABI-stable libraries where @inlinable even matters, such as the
> standard library and Apple SDK overlays, there's pretty much perfect
> overlap between things we want to inline and things we don't want to take
> up binary space and ABI surface in binaries, so the behavior Slava proposes
> seems like the right default.
>
>
> I disagree.  The semantics being proposed perfectly overlap with the
> transitional plan for overlays (which matters for the next few years), but
> they are the wrong default for anything other than overlays and the wrong
> thing for long term API evolution over the next 20 years.
>
>
> I disagree with this. 'inline' functions in C and C++ have to be backed by
> a symbol in the binary in order to guarantee function pointer identity, but
> we don't have that constraint. Without that constraint, there's almost no
> way that having a fallback definition in the binary is better:
>
> - It becomes an ABI compatibility liability that has to be preserved
> forever.
> - It increases binary size for a function that's rarely used, and which is
> often much larger as an outlined generic function than the simple operation
> that can be inlined into client code. Inlining makes the most sense when
> the inlined operation is smaller than a function call, so in many cases the
> net dylib + executable size would increase.
> - It increases the uncertainty of the behavior client code sees. If an
> inlinable function must always be emitted in the client, then client code
> *always* gets the current definition. If an inlinable function calls into
> the dylib when the compiler chooses not to inline it, then you may get the
> current definition, or you may get an older definition from any published
> version of the dylib. Ideally these all behave the same if the function is
> inlinable, but quirks are going to be inevitable.
>
> -Joe
>
>
> -Chris
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
i’m just tryna follow along here && this is probably a dumb question, but
is it possible for a generic function to be emitted as a set of specialized
functions into the client, but not inlined everywhere? It can be the case
where a large generic function gets slowed down by the large number of
generic operations inside it but it doesn’t make sense for it to be inlined
completely.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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/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’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 `atByteOffset:` and will only appear in
>>> UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in
>>> UnsafeMutableRawPointer, since we can just use pointer arithmetic now.
>>>
>>>
>>> *3*. move UnsafeMutableBufferPointer’s `at:` arguments to the front of
>>> the parameter list. mostly cause any pointer arithmetic happens in the
>>> front so structurally we want to mirror that.
>>>
>>> *4*. add dual (to:) single element initializers and assigners to
>>> UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s
>>> apparently not useful there. `UnsafeMutableRawPointer.initi
>>> alizeMemory(as:repeating:count:)` still loses its default count to
>>> prevent confusion with its buffer variant.
>>>
>>> *5*. memory deallocation on buffer pointers is clearly documented to
>>> only be defined behavior when the buffer matches a whole heap block.
>>>
>>>
>>> Kelvin,
>>>
>>> Attempting to limit the scope of this proposal backfired. I was hoping
>>> to avoid discussing changes to the slice API, instead providing basic
>>> functionality within the buffer API itself. However, Dave Abrahams has
>>> argued that once the slice API is extended, the positional arguments are
>>> extraneous and less clear.
>>>
>>> Instead of
>>>
>>>   buf.intialize(at: i, from: source)
>>>
>>> We want to force a more obvious idiom:
>>>
>>>   buf[i..>>
>>> I think this is a reasonable argument and convinced myself that it's
>>> possible to extend the slice API. I'm also convinced now that we don't need
>>> overloads to handle an UnsafeBufferPointer source, instead we can provide a
>>> single generic entry point on both UnsafeMutableBufferPointer and its
>>> slice, optimized within the implementation:
>>>
>>>  `initialize(from: S) -> (S.Iterator, Index)
>>>
>>> We can always drop down to the UnsafePointer API to get back to a direct
>>> unsafe implementation as a temporary workaround for performance issues.
>>>
>>> Let's set aside for now whether we support full or partial
>>> initialization/assignment, how to handle moveInitialize, and whether we
>>> need to return the Iterator/Index. This is going to require another
>>> iteration on swift-evolution, which *we should discuss in a separate
>>> thread*.
>>>
>>> At this point, I suggest removing the controversial aspects of SE-0184
>>> so that we can put the other changes behind us and focus future discussion
>>> around a smaller follow-up proposal.
>>>
>>> Here I've summarized the changes that I think could be accepted as-is:
>>> https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e
>>>
>>> If you amend SE-0184 accordingly and file a new PR, I think it can be
>>> quickly approved.
>>>
>>> -Andy
>>>
>>>
>> Part one of SE-0184 is here as SE-0184 A
>> <https://github.com/kelvin13/swift-evolution/blob/improved-pointers/proposals/0184a-unsafe-pointers-part-1.md>
>> I’ll implement it tomorrow and then make the PR
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Swift via swift-evolution]

> On Oct 4, 2017, at 6:41 AM, Alex Blewitt via swift-evolution 
>  wrote:
> 
>> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution 
>>  wrote:
>> 
>> on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong 
>>   wrote:
>> 
>> > Because, ideally, I’d love to be able to do:
>> > 
>> > infix operator and: LogicalConjunctionPrecedence // or whatever the 
>> > precedence is called
>> > func and(lhs: Bool, rhs: Bool) → Bool { return lhs && rhs }
>> > 
>> > let truthyValue = true and false
>> 
>> +1 (i like your thinking, even if it is unlikely to happen in swift)
>> 
>> (noteworthy, your example used "RIGHTWARDS ARROW" (U+2192) instead of ->, 
>> whether on purpose or not.)

Heh, right. That was unintentional. I have system text replacements set up to 
turn ->, =>, <->, etc in to their Unicode arrow versions: →, ⇒, ↔︎ 

And using words (and even phrases  like “is not”) as operators is totally 
possible. It would just require the parser to have a known list of all 
operators, and then greedily match characters as long as there’s an operator 
that’s prefixed by the current token, and then backtrack when it fails. 

I implemented this style of operator definition and parsing in my open source 
math parsing library: https://github.com/davedelong/DDMathParser 

Dave

>> 
>> speaking of &&, was it just a copy-paste from C or is there a more 
>> fundamental reason to use that instead of &? in C they had to use two 
>> different operators because of the implicit int <-> bool promotions, but in 
>> swift "true & false" vs "1 & 2" would have been distinguishable.
> 
> The difference between the & and && operators isn't to do with the implicit 
> conversions; it's to do with whether both sides of the expression are 
> evaluated or not.
> 
> false && system('rm -rf')
> 
> You really don't want to do that if both sides are executed ...
> 
> Alex
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 required for Math, CS, and
> maybe EE majors. Anyway, WRT a), if Swift achieves its "take over the
> world" goal, *all* use cases will be Swift use cases. WRT b), "many" as
> in the numerical quantity or "many" as in the percentage? There are
> probably millions of people who recognize calculus's operators, but there
> are 7.5 *billion* people in the world.
>

I’m 19 and for what it’s worth, set notation is “taught” in 9th grade but
no one really “learns” it until they get to discrete structures in college.
There’s a ton of random things that get introduced in high school/middle
school that no one ever retains. Believe it or not they teach set closure
in 6th grade, at least in my state.

It’s still my opinion that ⊆, ⊇, ∪, and friends make for obfuscated code
and I consider unicode operators to be one of the “toy” features of Swift.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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
handled by the compiler underneath all of that.

On Mon, Oct 2, 2017 at 11:45 PM, Slava Pestov  wrote:

>
> On Oct 2, 2017, at 9:15 PM, Xiaodi Wu  wrote:
>
>
> On Mon, Oct 2, 2017 at 22:23 Slava Pestov  wrote:
>
>> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu  wrote:
>>
>> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov  wrote:
>>
>>>
>>> On Oct 2, 2017, at 7:52 PM, Kelvin Ma  wrote:
>>>
>>> Is this only a problem with fileprivate or does it extend to private
>>> members too? I feel like this would be a very valuable feature to support.
>>>
>>>
>>> Private members too. Consider this example,
>>>
>>> struct S {
>>>   private func f() {}
>>> }
>>>
>>> The member S.f mangles as _T06struct1SV1f33_
>>> AB643CAAAE0894CD0BC8584D7CA3AD23LLyyF. In this case, I suppose we won’t
>>> need the private discriminator because there can only be one S.f that’s
>>> directly a member of S, and not an extension. However imagine if two
>>> different source files both defined extensions of S, with a private member
>>> f. You would need to disambiguate them somehow.
>>>
>>
>> The simple-minded way to do this would be to require @_versioned
>> annotations on private and fileprivate members to supply an internally
>> unique alternative name to be used for mangling-as-though-internal (i.e.
>> `@_versioned(my_extension_f)`). Such a function becoming public in an
>> ABI-compatible way would require renaming the "actual" name to the unique
>> @_versioned name.
>>
>>
>> We have _silgen_name for that, but we really don’t want to expose this
>> more generally because people have been abusing it to make things visible
>> to C, and they should be using @_cdecl instead.
>>
>
> The difference here would be that the "@_versioned name" would be subject
> to mangling. It's essentially equivalent to a way of specifying a custom
> discriminator to be hashed so that the source file name is omitted and not
> ABI. Not that I think it'd be elegant, but it would not be abusable like
> _silgen_name.
>
>
> That wouldn’t solve the problem where removing @_versioned(name) and
> adding public would change the symbol’s name.
>
> However, your idea of mangling versioned private symbols like internal and
> diagnosing conflicts might be workable.
>
> Slava
>
>
>
>> A more elegant refinement could be to have @_versioned private and
>> fileprivate members mangled as though internal, erroring if two or more
>> members with the same name are both @_versioned--would that work?
>>
>>
>> If you’re going to do that what is the value in having the capability at
>> all?
>>
>
> Solely to have some way of preventing members in one file from calling
> members in another file at compile time.
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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, 2017 at 6:42 PM, Xiaodi Wu  wrote:

>
> On Mon, Oct 2, 2017 at 17:41 Taylor Swift  wrote:
>
>> 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 doing this with underscored methods and variable names but I
>> don’t think that’s a good convention to use. We should have something at
>> the language level that enforces that something shouldn’t be referenced by
>> name outside of its scope, but is public for all compilation and ABI
>> purposes. Maybe an attribute like @visible or a new keyword or something.
>>
>
> Right, that’s @_versioned, essentially.
>
>
> On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> This is unduly restrictive; @_versioned (despite being the wrong
>>> spelling) is what we want here. To be callable from an inlinable function,
>>> internal things need only be visible in terms of public ABI, not
>>> necessarily inlinable, just as public things need only be public and not
>>> necessarily inlinable.
>>> On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution
>>>  wrote:
>>>
 On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov  wrote:

> Thanks for taking a look!
>
> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
> > 3. Even though @inlinable will have no effect on declarations which
> are not public, we should still allow it to be placed there. That way when
> the access level is later changed to be public, the attribute is already
> where it should be. This is similar to why we permit, eg., members of an
> internal type to be declared public, which was discussed and decided
> previously on Swift Evolution.
>
> This is an interesting point. Do you think the attribute should be
> completely ignored, or should the restrictions on references to non-public
> things, etc still be enforced?
>

  Hmm, good question!

 I rather like the idea Greg Parker put forth, where non-public
 @inlinable items can be used by public @inlinable ones, which implies that
 the restrictions should indeed still apply—something @inlinable can only
 reference public or @inlinable things.

 Nevin
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution

>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 system (see the Wikipedia article:
> https://en.wikipedia.org/wiki/Dependent_type?wprov=sfti1). Dependent
> types would allow for the type system to enforce certain correctness in
> design that otherwise would have to be test-based. It would also discourage
> type hacks that sort of implement it, but have poor semantics and clarity.
>
> Lemme give you an example:
> - Let’s say you want to make a modulo arithmetic library. It has
> applications in cryptography, but the fields existing there can also be
> used for complete and *exact* linear algebra operations.
> - Anyway. You want to make that. How?
> - You’d want to have a struct that represented a number from a modulo
> field.
> - These numbers can be multiplied, added, have inverses, etc.
> - But those operations only make sense if the prime P used for the modulo
> operation is the same between them. Otherwise, what’s the point?
> —> (Basically, you can’t just add (2 modulo 3) with (3 modulo 5). It
> doesn’t make sense)
> - You could do this in many different ways, and only a few (very hacky,
> “static class in a where clause”-like) will actually enforce this condition
> from the type system, which afaik is usually the best way to do so; both at
> compile time and at run time.
>
> On the other hand, having dependent types allows you to have exactly this
> kind of behavior:
> - Now you can define a “dependent type”, for example ModuloInteger,
> where P is the integer value that defines the type.
> - Like this, you’ll have:
> —> MI<2>: {0, 1}, where 1 + 1 = 0.
> —> MI<3>: {0, 1, 2}, where 1 + 1 = 2, and 2 • 2 = 1
> —> ... and so on.
> - Such a type system can be used for even stronger type qualities (read
> the Wikipedia article for good examples).
> - Such strong type qualities are super nice for any critical systems and
> for math libraries in general.
> - And I guess for just general correctness and documentation. It gives
> better semantics to our types.
>
> So, what do you say? Is this too crazy?
>
> Cheers,
> Félix
>
> Btw if you know Haskell (which I don’t, but appreciate), you can check a
> decent, Haskell-inspired, dependently typed language... here ~>
> https://www.idris-lang.org/
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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> wrote:

> Hi all,
>
> Here is a draft proposal that makes public a feature we’ve had for a
> while. Let me know what you think!
>
> Cross-module inlining and specialization ("@inlinable")
>
>- Proposal: SE-
>- Authors: Slava Pestov , Jordan Rose
>
>- Review Manager: TBD
>- Status: *Initial pitch*
>- Implementation: Already implemented as an underscored attribute
>@_inlineable
>
> Introduction
>
> We propose introducing an @inlinable attribute which exports the body of
> a function as part of a module's interface, making it available to the
> optimizer when referenced from other modules.
> Motivation
>
> One of the top priorities of the Swift 5 release is a design and
> implementation of *the Swift ABI*. This effort consists of three major
> tasks:
>
>-
>
>Finalizing the low-level function calling convention, layout of data
>types, and various runtime data structures. The goal here is to maintain
>compatibility across compiler versions, ensuring that we can continue to
>make improvements to the Swift compiler without breaking binaries built
>with an older version of the compiler.
>-
>
>Implementing support for *library evolution*, or the ability to make
>certain source-compatible changes, without breaking binary compatibility.
>Examples of source-compatible changes we are considering include adding new
>stored properties to structs and classes, removing private stored
>properties from structs and classes, adding new public methods to a class,
>or adding new protocol requirements that have a default implementation. The
>goal here is to maintain compatibility across framework versions, ensuring
>that framework authors can evolve their API without breaking binaries built
>against an older version of the framework. For more information about the
>resilience model, see the library evolution document
> in
>the Swift repository.
>-
>
>Stabilizing the API of the standard library. The goal here is to
>ensure that the standard library can be deployed separately from client
>binaries and frameworks, without forcing recompilation of existing code.
>
> All existing language features of Swift were designed with these goals in
> mind. In particular, the implementation of generic types and functions
> relies on runtime reified types to allow separate compilation and type
> checking of generic code.
>
> Within the scope of a single module, the Swift compiler performs very
> aggressive optimization, including full and partial specialization of
> generic functions, inlining, and various forms of interprocedural analysis.
>
> On the other hand, across module boundaries, runtime generics introduce
> unavoidable overhead, as reified type metadata must be passed between
> functions, and various indirect access patterns must be used to manipulate
> values of generic type. We believe that for most applications, this
> overhead is negligible compared to the actual work performed by the code
> itself.
>
> However, for some advanced use cases, and in particular for the standard
> library, the overhead of runtime generics can dominate any useful work
> performed by the library. Examples include the various algorithms defined
> in protocol extensions of Sequence and Collection, for instance the mapmethod
> of the Sequence protocol. Here the algorithm is very simple and spends
> most of its time manipulating generic values and calling to a user-supplied
> closure; specialization and inlining can completely eliminate the algorithm
> of the higher-order function call and generate equivalent code to a
> hand-written loop manipulating concrete types.
>
> We would like to annotate such functions with the @inlinable attribute.
> This will make their bodies available to the optimizer when building client
> code; on the other hand, calling such a function will cause it to be
> emitted into the client binary, meaning that if a library were to change
> the definition of such a function, only binaries built against the newer
> version of library will use the new definition.
> Proposed solution
>
> The @inlinable attribute causes the body of a function to be emitted as
> part of the module interface. For example, a framework can define a rather
> impractical implementation of an algorithm which returns true if all
> elements of a sequence are equal or if the sequence is empty, and false
> otherwise:
>
> @inlinable public func allEqual(_ seq: T) -> Bool
> where T : Sequence, T.Element : Equatable {

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

[Taylor Swift via swift-evolution]

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
doing this with underscored methods and variable names but I don’t think
that’s a good convention to use. We should have something at the language
level that enforces that something shouldn’t be referenced by name outside
of its scope, but is public for all compilation and ABI purposes. Maybe an
attribute like @visible or a new keyword or something.

On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> This is unduly restrictive; @_versioned (despite being the wrong spelling)
> is what we want here. To be callable from an inlinable function, internal
> things need only be visible in terms of public ABI, not necessarily
> inlinable, just as public things need only be public and not necessarily
> inlinable.
> On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov  wrote:
>>
>>> Thanks for taking a look!
>>>
>>> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
>>> nevin.brackettrozin...@gmail.com> wrote:
>>> > 3. Even though @inlinable will have no effect on declarations which
>>> are not public, we should still allow it to be placed there. That way when
>>> the access level is later changed to be public, the attribute is already
>>> where it should be. This is similar to why we permit, eg., members of an
>>> internal type to be declared public, which was discussed and decided
>>> previously on Swift Evolution.
>>>
>>> This is an interesting point. Do you think the attribute should be
>>> completely ignored, or should the restrictions on references to non-public
>>> things, etc still be enforced?
>>>
>>
>>  Hmm, good question!
>>
>> I rather like the idea Greg Parker put forth, where non-public @inlinable
>> items can be used by public @inlinable ones, which implies that the
>> restrictions should indeed still apply—something @inlinable can only
>> reference public or @inlinable things.
>>
>> Nevin
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 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, maybe we can allow a declaration (similar
> to how we define operators) that effectively pulls it into one of the other
> categories (not in terms of tokenization, but in terms of how it can be
> used in Swift).  Trying to pull it into both would be a compilation error.
>
> That way, Xiaodi can have a framework which lets her use superscript T as
> an identifier, and I can have one where I use superscript 2 to square
> things.  The obvious/frequently used characters would not be ambiguous, so
> it would only slow down compilation when the rare/ambiguous characters are
> used.
>
> In my mind, this would be the ideal solution, and it could be done in
> stages (with the ambiguous characters just being forbidden for now), but I
> am not sure if it is technically possible.
>
> Thanks,
> Jon
>
> On Sep 30, 2017, at 3:59 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> The core team recently met to discuss PR609 - Refining identifier and
> operator symbology:
> https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638
> f31926c9c3/proposals/-refining-identifier-and-operator-symbology.md
>
> The proposal correctly observes that the partitioning of unicode
> codepoints into identifiers and operators is a mess in some cases.  It
> really is an outright bug for 🙂 to be an identifier, but ☹️ to be an
> operator.  That said, the proposal itself is complicated and is defined in
> terms of a bunch of unicode classes that may evolve in the “wrong way for
> Swift” in the future.
>
> The core team would really like to get this sorted out for Swift 5, and
> sooner is better than later :-).  Because it seems that this is a really
> hard problem and that perfection is becoming the enemy of good
> , the core
> team requests the creation of a new proposal with a different approach.
> The general observation is that there are three kinds of characters: things
> that are obviously identifiers, things that are obviously math operators,
> and things that are non-obvious.  Things that are non-obvious can be made
> into invalid code points, and legislated later in follow-up proposals
> if/when someone cares to argue for them.
>
>
> To make progress on this, we suggest a few separable steps:
>
> First, please split out the changes to the ASCII characters (e.g. . and \
> operator parsing rules) to its own (small) proposal, since it is unrelated
> to the unicode changes, and can make progress on that proposal
> independently.
>
>
> Second, someone should take a look at the concrete set of unicode
> identifiers that are accepted by Swift 4 and write a new proposal that
> splits them into the three groups: those that are clearly identifiers
> (which become identifiers), those that are clearly operators (which become
> operators), and those that are unclear or don’t matter (these become
> invalid code points).
>
> I suggest that the criteria be based on *utility for Swift code*, not on
> the underlying unicode classification.  For example, the discussion thread
> for PR609 mentions that the T character in “  xᵀ  ” is defined in unicode
> as a latin “letter”.  Despite that, its use is Swift would clearly be as a
> postfix operator, so we should classify it as an operator.
>
> Other suggestions:
>  - Math symbols are operators excepting those primarily used as
> identifiers like “alpha”.  If there are any characters that are used for
> both, this proposal should make them invalid.
>  - While there may be useful ranges for some identifiers (e.g. to handle
> european accented characters), the Emoji range should probably have each
> codepoint independently judged, and currently unassigned codepoints should
> not get a meaning defined for them.
>  - Unicode “faces”, “people”, “animals” etc are all identifiers.
>  - In order to reduce the scope of the proposal, it is a safe default to
> exclude characters that are unlikely to be used by Swift code today,
> including Braille, weird currency symbols, or any set of characters that
> are so broken and useless in Swift 4 that it isn’t worth worrying about.
>  - The proposal is likely to turn a large number of code points into
> rejected characters.  In the discussions, some people will be tempted to
> argue endlessly about individual rejections.  To control that, we can
> require that people point out an example where the character is already in
> use, or where it has a clear application to a domain that is known today:
> the disc

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

[Taylor Swift via swift-evolution]

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, 2017 at 6:51 PM, Dave Abrahams  wrote:

> 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 though I
> understand why you want to read it that way, in particular *because* of
> the precedent I cited.
>
> On Sep 30, 2017, at 4:23 PM, Taylor Swift  wrote:
>
> 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 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:
>>
>>>
>>>
>>> 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 argument
>>> from the source argument. So what would really have to be written is
>>>
>>> buf[i ..< i + source.count].initialize(from: source)
>>>
>>> which is a lot more ugly and redundant. One option could be to decouple
>>> the count parameter from the length of the source buffer, but that opens up
>>> the whole can of worms in which length do we use? What happens if n - i is
>>> less than or longer than source.count? If we enforce the precondition
>>> that source.count == n - i, then this syntax seems horribly redundant.
>>>
>>>
>>> Sorry, a better analogy would have been:
>>>
>>>  buf[i...].intialize(from: source)
>>>
>>> Whether you specify the slice’s end point depends on whether you want to
>>> completely initialize that slice or whether you’re just filling up as much
>>> of the buffer as you can. It also depends on whether `source` is also a
>>> buffer (of known size) or some arbitrary Sequence.
>>>
>>> Otherwise, point  taken.
>>>
>>> -Andy
>>>
>>
>> After thinking about this more, one-sided ranges might provide just the
>> expressivity we need. What if:
>>
>> buf[offset...].initialize(from: source) // initializes source.count
>> elements from source starting from offset
>>
>> buf[offset ..< endIndex].initialize(from: source) // initializes up to
>> source.count elements from source starting from offset
>>
>>
>> The one sided one does not give a full initialization guarantee. The two
>> sided one guarantees the entire segment is initialized.
>>
>>
>> In every other context, x[i...] is equivalent to x[i..>
>> I don't think breaking that precedent is a good idea.
>>
>> For move operations, the one sided one will fully deinitialize the source
>> buffer while the two sided one will only deinitialize endIndex - offset
>> elements.
>>
>>
>> —
>> -Dave
>>
>>
>> well since people want to use subscript notation so much we need some way
>> of expressing case 1. writing both bounds in the subscript seems to imply a
>> full initialization (and thus partial movement) guarantee.
>>
>>
>> Yes, I understood your reasoning.  Do you understand why I still don't
>> want to proceed in that direction?
>>
>> —
>> -Dave
>>
>>
>>
>>
>>
>>
>
> —
> -Dave
>
>
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 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:
>
>>
>>
>> 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 argument
>> from the source argument. So what would really have to be written is
>>
>> buf[i ..< i + source.count].initialize(from: source)
>>
>> which is a lot more ugly and redundant. One option could be to decouple
>> the count parameter from the length of the source buffer, but that opens up
>> the whole can of worms in which length do we use? What happens if n - i is
>> less than or longer than source.count? If we enforce the precondition
>> that source.count == n - i, then this syntax seems horribly redundant.
>>
>>
>> Sorry, a better analogy would have been:
>>
>>  buf[i...].intialize(from: source)
>>
>> Whether you specify the slice’s end point depends on whether you want to
>> completely initialize that slice or whether you’re just filling up as much
>> of the buffer as you can. It also depends on whether `source` is also a
>> buffer (of known size) or some arbitrary Sequence.
>>
>> Otherwise, point  taken.
>>
>> -Andy
>>
>
> After thinking about this more, one-sided ranges might provide just the
> expressivity we need. What if:
>
> buf[offset...].initialize(from: source) // initializes source.count
> elements from source starting from offset
>
> buf[offset ..< endIndex].initialize(from: source) // initializes up to
> source.count elements from source starting from offset
>
>
> The one sided one does not give a full initialization guarantee. The two
> sided one guarantees the entire segment is initialized.
>
>
> In every other context, x[i...] is equivalent to x[i..
> I don't think breaking that precedent is a good idea.
>
> For move operations, the one sided one will fully deinitialize the source
> buffer while the two sided one will only deinitialize endIndex - offset
> elements.
>
>
> —
> -Dave
>
>
> well since people want to use subscript notation so much we need some way
> of expressing case 1. writing both bounds in the subscript seems to imply a
> full initialization (and thus partial movement) guarantee.
>
>
> Yes, I understood your reasoning.  Do you understand why I still don't
> want to proceed in that direction?
>
> —
> -Dave
>
>
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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’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 `atByteOffset:` and will only appear in
>> UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in
>> UnsafeMutableRawPointer, since we can just use pointer arithmetic now.
>>
>>
>> *3*. move UnsafeMutableBufferPointer’s `at:` arguments to the front of
>> the parameter list. mostly cause any pointer arithmetic happens in the
>> front so structurally we want to mirror that.
>>
>> *4*. add dual (to:) single element initializers and assigners to
>> UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s
>> apparently not useful there. `UnsafeMutableRawPointer.initi
>> alizeMemory(as:repeating:count:)` still loses its default count to
>> prevent confusion with its buffer variant.
>>
>> *5*. memory deallocation on buffer pointers is clearly documented to
>> only be defined behavior when the buffer matches a whole heap block.
>>
>>
>> Kelvin,
>>
>> Attempting to limit the scope of this proposal backfired. I was hoping to
>> avoid discussing changes to the slice API, instead providing basic
>> functionality within the buffer API itself. However, Dave Abrahams has
>> argued that once the slice API is extended, the positional arguments are
>> extraneous and less clear.
>>
>> Instead of
>>
>>   buf.intialize(at: i, from: source)
>>
>> We want to force a more obvious idiom:
>>
>>   buf[i..>
>> I think this is a reasonable argument and convinced myself that it's
>> possible to extend the slice API. I'm also convinced now that we don't need
>> overloads to handle an UnsafeBufferPointer source, instead we can provide a
>> single generic entry point on both UnsafeMutableBufferPointer and its
>> slice, optimized within the implementation:
>>
>>  `initialize(from: S) -> (S.Iterator, Index)
>>
>> We can always drop down to the UnsafePointer API to get back to a direct
>> unsafe implementation as a temporary workaround for performance issues.
>>
>> Let's set aside for now whether we support full or partial
>> initialization/assignment, how to handle moveInitialize, and whether we
>> need to return the Iterator/Index. This is going to require another
>> iteration on swift-evolution, which *we should discuss in a separate
>> thread*.
>>
>> At this point, I suggest removing the controversial aspects of SE-0184 so
>> that we can put the other changes behind us and focus future discussion
>> around a smaller follow-up proposal.
>>
>> Here I've summarized the changes that I think could be accepted as-is:
>> https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e
>>
>> If you amend SE-0184 accordingly and file a new PR, I think it can be
>> quickly approved.
>>
>> -Andy
>>
>>
> Part one of SE-0184 is here as SE-0184 A
> 
> I’ll implement it tomorrow and then make the PR
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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:
>>
>> 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 `atByteOffset:` and will only appear in
>> UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in
>> UnsafeMutableRawPointer, since we can just use pointer arithmetic now.
>>
>>
>> *3*. move UnsafeMutableBufferPointer’s `at:` arguments to the front of
>> the parameter list. mostly cause any pointer arithmetic happens in the
>> front so structurally we want to mirror that.
>>
>> *4*. add dual (to:) single element initializers and assigners to
>> UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s
>> apparently not useful there. `UnsafeMutableRawPointer.initi
>> alizeMemory(as:repeating:count:)` still loses its default count to
>> prevent confusion with its buffer variant.
>>
>> *5*. memory deallocation on buffer pointers is clearly documented to
>> only be defined behavior when the buffer matches a whole heap block.
>>
>>
>> Kelvin,
>>
>> Attempting to limit the scope of this proposal backfired. I was hoping to
>> avoid discussing changes to the slice API, instead providing basic
>> functionality within the buffer API itself. However, Dave Abrahams has
>> argued that once the slice API is extended, the positional arguments are
>> extraneous and less clear.
>>
>> Instead of
>>
>>   buf.intialize(at: i, from: source)
>>
>> We want to force a more obvious idiom:
>>
>>   buf[i..>
>> I think this is a reasonable argument and convinced myself that it's
>> possible to extend the slice API. I'm also convinced now that we don't need
>> overloads to handle an UnsafeBufferPointer source, instead we can provide a
>> single generic entry point on both UnsafeMutableBufferPointer and its
>> slice, optimized within the implementation:
>>
>>  `initialize(from: S) -> (S.Iterator, Index)
>>
>> We can always drop down to the UnsafePointer API to get back to a direct
>> unsafe implementation as a temporary workaround for performance issues.
>>
>> Let's set aside for now whether we support full or partial
>> initialization/assignment, how to handle moveInitialize, and whether we
>> need to return the Iterator/Index. This is going to require another
>> iteration on swift-evolution, which *we should discuss in a separate
>> thread*.
>>
>> At this point, I suggest removing the controversial aspects of SE-0184 so
>> that we can put the other changes behind us and focus future discussion
>> around a smaller follow-up proposal.
>>
>> Here I've summarized the changes that I think could be accepted as-is:
>> https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e
>>
>> If you amend SE-0184 accordingly and file a new PR, I think it can be
>> quickly approved.
>>
>> -Andy
>>
>>
> Part one of SE-0184 is here as SE-0184 A
> 
> I’ll implement it tomorrow and then make the PR
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 this
> proposal
>
> *2*. change raw offsets to be in terms of bytes, not typed strides. This
> argument will be called `atByteOffset:` and will only appear in
> UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in
> UnsafeMutableRawPointer, since we can just use pointer arithmetic now.
>
>
> *3*. move UnsafeMutableBufferPointer’s `at:` arguments to the front of
> the parameter list. mostly cause any pointer arithmetic happens in the
> front so structurally we want to mirror that.
>
> *4*. add dual (to:) single element initializers and assigners to
> UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s
> apparently not useful there. `UnsafeMutableRawPointer.initi
> alizeMemory(as:repeating:count:)` still loses its default count to
> prevent confusion with its buffer variant.
>
> *5*. memory deallocation on buffer pointers is clearly documented to only
> be defined behavior when the buffer matches a whole heap block.
>
>
> Kelvin,
>
> Attempting to limit the scope of this proposal backfired. I was hoping to
> avoid discussing changes to the slice API, instead providing basic
> functionality within the buffer API itself. However, Dave Abrahams has
> argued that once the slice API is extended, the positional arguments are
> extraneous and less clear.
>
> Instead of
>
>   buf.intialize(at: i, from: source)
>
> We want to force a more obvious idiom:
>
>   buf[i..
> I think this is a reasonable argument and convinced myself that it's
> possible to extend the slice API. I'm also convinced now that we don't need
> overloads to handle an UnsafeBufferPointer source, instead we can provide a
> single generic entry point on both UnsafeMutableBufferPointer and its
> slice, optimized within the implementation:
>
>  `initialize(from: S) -> (S.Iterator, Index)
>
> We can always drop down to the UnsafePointer API to get back to a direct
> unsafe implementation as a temporary workaround for performance issues.
>
> Let's set aside for now whether we support full or partial
> initialization/assignment, how to handle moveInitialize, and whether we
> need to return the Iterator/Index. This is going to require another
> iteration on swift-evolution, which *we should discuss in a separate
> thread*.
>
> At this point, I suggest removing the controversial aspects of SE-0184 so
> that we can put the other changes behind us and focus future discussion
> around a smaller follow-up proposal.
>
> Here I've summarized the changes that I think could be accepted as-is:
> https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e
>
> If you amend SE-0184 accordingly and file a new PR, I think it can be
> quickly approved.
>
> -Andy
>
>
Part one of SE-0184 is here as SE-0184 A

I’ll implement it tomorrow and then make the PR
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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:
>
>>
>>
>> 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 argument
>> from the source argument. So what would really have to be written is
>>
>> buf[i ..< i + source.count].initialize(from: source)
>>
>> which is a lot more ugly and redundant. One option could be to decouple
>> the count parameter from the length of the source buffer, but that opens up
>> the whole can of worms in which length do we use? What happens if n - i is
>> less than or longer than source.count? If we enforce the precondition
>> that source.count == n - i, then this syntax seems horribly redundant.
>>
>>
>> Sorry, a better analogy would have been:
>>
>>  buf[i...].intialize(from: source)
>>
>> Whether you specify the slice’s end point depends on whether you want to
>> completely initialize that slice or whether you’re just filling up as much
>> of the buffer as you can. It also depends on whether `source` is also a
>> buffer (of known size) or some arbitrary Sequence.
>>
>> Otherwise, point  taken.
>>
>> -Andy
>>
>
> After thinking about this more, one-sided ranges might provide just the
> expressivity we need. What if:
>
> buf[offset...].initialize(from: source) // initializes source.count
> elements from source starting from offset
>
> buf[offset ..< endIndex].initialize(from: source) // initializes up to
> source.count elements from source starting from offset
>
>
> The one sided one does not give a full initialization guarantee. The two
> sided one guarantees the entire segment is initialized.
>
>
> In every other context, x[i...] is equivalent to x[i..
> I don't think breaking that precedent is a good idea.
>
> For move operations, the one sided one will fully deinitialize the source
> buffer while the two sided one will only deinitialize endIndex - offset
> elements.
>
>
> —
> -Dave
>
>
> well since people want to use subscript notation so much we need some way
> of expressing case 1. writing both bounds in the subscript seems to imply a
> full initialization (and thus partial movement) guarantee.
>
>
> Presumably, in your use case, you’re working directly with buffers on both
> sides (please point us to the real code). With the slicing approach, that
> would be done as follows:
>
> bufA[i ..< i + bufB.count].initialize(from: bufB)
>
> That will enforce full initialization of the slice:
> precondition(self.count == source.count).
>
> Your point stands that it is redundant. That point will need to be weighed
> against other points, which I think should be discussed in another thread.
>
> -Andy
>

To this and your other method about the real library code; right now the
PNG library doesn’t use buffer methods (since they don’t exist yet) and
pixels are plain-old-data so i’m not using the memory state API there
anyway (the original proposal didn’t even have anything to do with those
APIs actually). However I did take a few minutes to write a quick queue
implementation

in Swift which does not make any assumptions about the Element type. I then
rewrote it using the hypothetical buffer API I proposed, and then the
hypothetical buffer API using subscript notation.



*These are the relevant function calls using the current API (the rest of
the code has been stripped out)*

newBuffer:UnsafeMutablePointer =
UnsafeMutablePointer.allocate(capacity:
newCapacity)

newBuffer  .moveInitialize( from:  buffer + self.zero,
count:
self.capacity - self.zero)
(newBuffer + self.zero).moveInitialize( from:  buffer,
count: self.zero)
buffer.deallocate(capacity: self.capacity)

(self.buffer! + self.bufferPosition(of: self.count)).initialize(to:
data)

let dequeued:Element = (self.buffer! + self.zero).move()

*These are the function calls using the SE 184 API *

newBuffer:UnsafeMutableBufferPointer =
UnsafeMutableBufferPointer.allocate(capacity:
newCapacity)

newBuffer.moveInitialize(at: 0, from:
self.buffer[self.zero...   ])
newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..<
self.zero])
self.buffer.deallocate()

(self.buffer.baseAddress! + self.bufferPosition(of:
self.count)).initialize(to: data)

let dequeued:Element = (self.buffer! + self.zero).move()

*And with the proposed subscript notation*

newB

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

[Taylor Swift via swift-evolution]

> 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.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 argument 
 from the source argument. So what would really have to be written is 
 
 buf[i ..< i + source.count].initialize(from: source) 
 
 which is a lot more ugly and redundant. One option could be to decouple 
 the count parameter from the length of the source buffer, but that opens 
 up the whole can of worms in which length do we use? What happens if n - i 
 is less than or longer than source.count? If we enforce the precondition 
 that source.count == n - i, then this syntax seems horribly redundant. 
>>> 
>>> Sorry, a better analogy would have been:
>>> 
>>>  buf[i...].intialize(from: source)
>>> 
>>> Whether you specify the slice’s end point depends on whether you want to 
>>> completely initialize that slice or whether you’re just filling up as much 
>>> of the buffer as you can. It also depends on whether `source` is also a 
>>> buffer (of known size) or some arbitrary Sequence.
>>> 
>>> Otherwise, point  taken.
>>> 
>>> -Andy
>> 
>> After thinking about this more, one-sided ranges might provide just the 
>> expressivity we need. What if:
>> 
>> buf[offset...].initialize(from: source) // initializes source.count elements 
>> from source starting from offset
>> 
>> buf[offset ..< endIndex].initialize(from: source) // initializes up to 
>> source.count elements from source starting from offset
>> 
>> 
>> The one sided one does not give a full initialization guarantee. The two 
>> sided one guarantees the entire segment is initialized.
> 
> In every other context, x[i...] is equivalent to x[i.. 
> I don't think breaking that precedent is a good idea.
> 
>> For move operations, the one sided one will fully deinitialize the source 
>> buffer while the two sided one will only deinitialize endIndex - offset 
>> elements. 
> 
> —
> -Dave

well since people want to use subscript notation so much we need some way of 
expressing case 1. writing both bounds in the subscript seems to imply a full 
initialization (and thus partial movement) guarantee.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 argument
> from the source argument. So what would really have to be written is
>
> buf[i ..< i + source.count].initialize(from: source)
>
> which is a lot more ugly and redundant. One option could be to decouple
> the count parameter from the length of the source buffer, but that opens up
> the whole can of worms in which length do we use? What happens if n - i is
> less than or longer than source.count? If we enforce the precondition that
>  source.count == n - i, then this syntax seems horribly redundant.
>
>
> Sorry, a better analogy would have been:
>
>  buf[i...].intialize(from: source)
>
> Whether you specify the slice’s end point depends on whether you want to
> completely initialize that slice or whether you’re just filling up as much
> of the buffer as you can. It also depends on whether `source` is also a
> buffer (of known size) or some arbitrary Sequence.
>
> Otherwise, point  taken.
>
> -Andy
>

After thinking about this more, one-sided ranges might provide just the
expressivity we need. What if:

buf[offset...].initialize(from: source) // initializes source.count
elements from source starting from offset

buf[offset ..< endIndex].initialize(from: source) // initializes up to
source.count elements from source starting from offset


The one sided one does not give a full initialization guarantee. The two
sided one guarantees the entire segment is initialized. For move
operations, the one sided one will fully deinitialize the source buffer
while the two sided one will only deinitialize endIndex - offset elements.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 this
> proposal
>
> *2*. change raw offsets to be in terms of bytes, not typed strides. This
> argument will be called `atByteOffset:` and will only appear in
> UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in
> UnsafeMutableRawPointer, since we can just use pointer arithmetic now.
>
>
> *3*. move UnsafeMutableBufferPointer’s `at:` arguments to the front of
> the parameter list. mostly cause any pointer arithmetic happens in the
> front so structurally we want to mirror that.
>
> *4*. add dual (to:) single element initializers and assigners to
> UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s
> apparently not useful there. `UnsafeMutableRawPointer.initi
> alizeMemory(as:repeating:count:)` still loses its default count to
> prevent confusion with its buffer variant.
>
> *5*. memory deallocation on buffer pointers is clearly documented to only
> be defined behavior when the buffer matches a whole heap block.
>
>
> Kelvin,
>
> Attempting to limit the scope of this proposal backfired. I was hoping to
> avoid discussing changes to the slice API, instead providing basic
> functionality within the buffer API itself. However, Dave Abrahams has
> argued that once the slice API is extended, the positional arguments are
> extraneous and less clear.
>
> 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 argument from
the source argument. So what would really have to be written is

buf[i ..< i + source.count].initialize(from: source)

which is a lot more ugly and redundant. One option could be to decouple the
count parameter from the length of the source buffer, but that opens up the
whole can of worms in which length do we use? What happens if n - i is less
than or longer than source.count? If we enforce the precondition that
source.count
== n - i, then this syntax seems horribly redundant.


> I think this is a reasonable argument and convinced myself that it's
> possible to extend the slice API. I'm also convinced now that we don't need
> overloads to handle an UnsafeBufferPointer source, instead we can provide a
> single generic entry point on both UnsafeMutableBufferPointer and its
> slice, optimized within the implementation:
>
>  `initialize(from: S) -> (S.Iterator, Index)
>
> We can always drop down to the UnsafePointer API to get back to a direct
> unsafe implementation as a temporary workaround for performance issues.
>

Using Sequences throws out a whole host of assumptions we’ve been taking
advantage of. We can’t check for source.count anymore since that requires
traversing the entire Sequence. And if the performance is so bad relative
to the UnsafePointer API, we have to ask what the purpose of such a buffer
API would even be. The whole purpose of the buffer API was to make it
easier to do things with pointers without having to keep track of buffer
lengths externally. It should be built around the UnsafePointer API, not
the much higher level Sequence API.


>
> Let's set aside for now whether we support full or partial
> initialization/assignment, how to handle moveInitialize, and whether we
> need to return the Iterator/Index. This is going to require another
> iteration on swift-evolution, which *we should discuss in a separate
> thread*.
>
> At this point, I suggest removing the controversial aspects of SE-0184 so
> that we can put the other changes behind us and focus future discussion
> around a smaller follow-up proposal.
>
> Here I've summarized the changes that I think could be accepted as-is:
> https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e
>
> If you amend SE-0184 accordingly and file a new PR, I think it can be
> quickly approved.
>
> -Andy
>
>
fine with me i guess
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Resources

[Taylor Swift via swift-evolution]

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!
> >
> > I’m really happy that Swift 4 is out, and it’s great that there’s
> already so much active discussion about Swift 5 (concurrency, etc). I find
> I’m running in to language roadblocks less and less, and the improvements
> to the generics system have really improved a lot of my code. It’s really
> enjoyable to program in Swift, so thanks to everybody who made it possible.
> >
> > When I think about what’s missing from Swift, I think of modules. We all
> like to write modular code, and aside from the entire discussion about
> submodules, the way that you glue separate modules together in to an
> application is supposed to be via the package manager. For Swift 5, I would
> personally really like it if we could flesh out the package manager a bit
> more so that it can really be the basis of a thriving Swift developer
> community in production environments.
> >
> > The thing that hits me the most with SwiftPM currently is that it
> doesn’t support resources, and it has very limited support for
> cross-platform modules (the type of thing you’re likely to have as a Model
> or Model Controller layer). Without support for bundled application
> resources, there’s no way for the package manager to support GUI apps or
> frameworks and unit-tests can’t reliably point to bundled test resources.
> >
> > I have some ideas about ways we could improve the situation, but first I
> thought I’d send this out for some community feedback. Do you think SwiftPM
> is as important as I do for v5? Which improvements would give you the most
> benefit?
> >
> > - Karl
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> Title is rubbish (copy/paste error). Should be “SwiftPM in Swift5”.
>
> But seriously, one of the themes from the discussions in the past release
> was that “there’s no good library for X” or “when will people use Swift for
> Y?”. I believe the package manager is a big hurdle to getting more, great
> libraries in wider use. CocoaPods is far from sufficient. Thinking about
> this hypothetical future Xcode integration; how is that even supposed to
> happen when the package manager doesn’t support Apps with bundled resources
> (like icons)?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

great work! it looks like there is quite a lot of duplicated work going on
here though which is unfortunate. how do we reconcile these 2
implementations?

On Thu, Sep 21, 2017 at 12:16 PM, Aleksey Mashanov <
aleksey.masha...@gmail.com> wrote:

> I have an alternative implementation of a URI (a superset of URL). It is
> quite ready to use but still requires some polishing and adding of
> additional specific URI schemes.
> It is designed primarily for server side usage but can be useful on a
> client too. The main goals of the design is correctness (according to
> 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
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038923.html>
>> 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 is currently little more than a wrapper for
>> NSURL), so I’ve just started a pure Swift URL library project at <
>> https://github.com/kelvin13/url>.
>>
>> The library’s parsing and validation core (~1K loc pure swift) is already
>> in place and functional; the goal is to eventually support all of the
>> Foundation URL functionality.
>>
>> The new `URL` type is implemented as a value type with utf8 storage
>> backed by an array buffer. The URLs are just 56 bytes long each, so they
>> should be able to fit into cache lines. (NSURL by comparison is over 128
>> bytes in size; it’s only saved by the fact that the thing is passed as a
>> reference type.)
>>
>> As I said, this is still really early on and not a mature library at all
>> but everyone is invited to observe, provide feedback, or contribute!
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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, I like conditional conformances
> and synthesized implementation of protocol methods, but I find that they
> both make it harder to figure out what I need to implement, and what are
> going to be the performance characteristics of methods that I choose to not
> implement.
>
>
>
> If you're thinking specifically about the standard library, the
> documentation for protocols like Sequence shows whether a member is
> required, and whether it provides a default implementation.
>
> https://developer.apple.com/documentation/swift/sequence#2923865
>
> Have you noticed that before, or is it still tricky to find requirements
> given the presentation?
>
> -Kyle
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 Swift Evolution previously. It's
>> interesting to me that Steve Canon is so certain that CSPRNGs are the way
>> to go. I wasn't aware that hardware CSPRNGs have come such a long way and
>> are so ubiquitous as to be feasible as a basis for Swift random numbers. If
>> so, great.
>>
>> Otherwise, if there is any way that a software, non-cryptographically
>> secure PRNG is going to outperform a CSPRNG, then I think it's worthwhile
>> to have a (carefully documented) choice between the two. I would imagine
>> that for many uses, such as an animation in which you need a plausible
>> source of noise to render a flame, whether that is cryptographically secure
>> or not is absolutely irrelevant but performance may be key.
>>
>>
>> Let me be precise: it is absolutely possible to outperform CSPRNGs. They
>> have simply become fast enough that the performance gap doesn’t matter for
>> most uses (let’s say amortized ten cycles per byte or less—whatever you are
>> going to do with the random bitstream will be much more expensive than
>> getting the bits was).
>>
>> That said, yes, there should definitely be other options. It should be
>> possible for users to get reproducible results from a stdlib random
>> interface run-to-run, and also across platforms. That alone requires that
>> at least one other option for a generator be present. There may also be a
>> place for a very high-throughput generator like xorshiro128+.
>>
>> All I’m really saying is that the *default* generator should be an
>> os-provided unseeded CSPRNG, and we should be very careful about
>> documenting any generator options.
>>
>
>
> Agree on all points. Much like Swift's strings are Unicode-correct instead
> of the fastest possible way of slicing and dicing sequences of ASCII
> characters, Swift's default PRNG should be cryptographically secure.
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> I would argue that anyone doing cryptography probably already knows how
important RNG selection is and can be expected to look for a specialized
cryptographically secure RNG. I doubt they would just use the default RNG
without first checking the documentation.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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
backwards compatibility. Instead it should go into its own Random core
module.

On Fri, Sep 8, 2017 at 11:52 AM, Alejandro Alonso via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello swift evolution, I would like to propose a unified approach to
> `random()` in Swift. I have a simple implementation here
> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5. This
> implementation is a simple wrapper over existing random functions so
> existing code bases will not be affected. Also, this approach introduces a
> new random feature for Linux users that give them access to upper bounds,
> as well as a lower bound for both Glibc and Darwin users. This change would
> be implemented within Foundation.
>
> I believe this simple change could have a very positive impact on new
> developers learning Swift and experienced developers being able to write
> single random declarations.
>
> I’d like to hear about your ideas on this proposal, or any implementation
> changes if need be.
>
> - Alejando
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 
> `CountableClosedRange`?
> 
>> On Sep 8, 2017, 12:08 PM -0500, Shawn Erickson , wrote:
>> It would be nice to leverage range support instead of a start and end value 
>> IMHO.
>>> On Fri, Sep 8, 2017 at 9:52 AM Alejandro Alonso via swift-evolution 
>>>  wrote:
>>> Hello swift evolution, I would like to propose a unified approach to 
>>> `random()` in Swift. I have a simple implementation here 
>>> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5. This 
>>> implementation is a simple wrapper over existing random functions so 
>>> existing code bases will not be affected. Also, this approach introduces a 
>>> new random feature for Linux users that give them access to upper bounds, 
>>> as well as a lower bound for both Glibc and Darwin users. This change would 
>>> be implemented within Foundation.
>>> 
>>> I believe this simple change could have a very positive impact on new 
>>> developers learning Swift and experienced developers being able to write 
>>> single random declarations.
>>> 
>>> I’d like to hear about your ideas on this proposal, or any implementation 
>>> changes if need be.
>>> 
>>> - Alejando
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 optimizations that could improve the
   performance of the Swift heap. however, these optimizations are not in
   place yet, nor will they be any time soon, so dropping the parameter would
   result in no performance regressions.
   - users coming from C/C++ are used to the malloc(_:) – free() pattern.
   Swift should support this both for learnability, and for
malloc-compatibility.

   - completely departing from the malloc memory model might save a few
   bytes of headers in the heap, but as discussed in this thread, there are
   other upsides of Swift being malloc-compatible.
   - there is nothing preventing us from reintroducing
   deallocate(allocatedCapacity:) in the future, once the runtime actually
   supports this feature. informed users looking for a performance boost could
   opt-in to use this API instead.
   - deprecating, and then un-deprecating deallocate(capacity:) might sound
   extra, but keeping this method unbothered is actually a bad idea. whoever
   is using it right now, is probably not using it correctly. The best
   strategy is to reintroduce it later as a well-documented *opt-in*
   feature. Grandfathering in old incorrect code offers no benefits and many
   problems.
   - lying to users is never a good idea. for the forseeable future,
   Heap.cpp calls free(), and Swift shouldn’t pretend like it supports
   something it doesn’t support.




On Thu, Sep 7, 2017 at 8:18 PM, Andrew Trick  wrote:

>
> On Sep 7, 2017, at 5:56 PM, Jordan Rose  wrote:
>
>
>
> On Sep 7, 2017, at 17:46, Andrew Trick  wrote:
>
>
> On Sep 7, 2017, at 5:40 PM, Joe Groff  wrote:
>
>
>
> But then given that, I don't understand why the 'capacity' parameter is
> necessary. Under what circumstances would it actually be faster than "just"
> calling malloc_size?
>
>
> The runtime may need to hash the address or traverse a lookup table to
> find out which allocation pool the block resides in. Now, that’s only if
> some platform ditches full malloc compatibility for user allocations, so
> I’m not sure how realistic it is.
>
>
> It seems to me that you could still provide malloc/free compatibility with
> a zone that had to do a relatively expensive traversal on free() to recover
> the pool the memory came from; malloc/free just wouldn't be the ideal
> interface in that situation.
>
> -Joe
>
>
> Joe is right, and I just learned how amazing malloc zones are.
>
>
> As long as you support multiple allocators (or hide everything behind
> malloc/free), there's already a cost of malloc_zone_from_ptr or equivalent.
> Without seeing a concrete use case, I wouldn't want to stay with the
> harder-to-use API *in UnsafePointer itself.* It might be a feature of a
> *particular* allocator that you need to keep the capacity around, but it
> *isn't* something generally true about Swift's memory model, and probably
> never will be.
>
> (Interesting reference points: malloc/malloc.h and the implementation of
> malloc on macOS
> 
>  -
> search for "free(void *ptr)".)
>
> Jordan
>
>
> I’m primarily arguing from the point of view that UnsafeBufferPointer
> should pass it’s deallocation capacity and should be implementable in terms
> of UnsafePointer. But I’m fine hiding the capacity argument from the public
> API for now. We know what the proposal author wants to do, so unless Joe
> still feels strongly, we could accept the proposal as-is, put the API
> decision to rest and focus on better documentation and and assertions.
>
> -Andy
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

> 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, 2017, at 8:06 AM, Taylor Swift  wrote:
> 
> I don’t see any source for this claim in the documentation, or the source 
> code. As far as I can tell the expected behavior is that partial 
> deallocation “should” work.
> 
>> On Thu, Sep 7, 2017 at 8:59 AM, Joe Groff  wrote:
>> 
>> The segfaulting example is an incorrect usage. The only valid parameters 
>> to deallocate(capacity:) are the base address of an allocation, and the 
>> original capacity passed into allocate(); it has never been intended to 
>> support partial deallocation of allocated blocks. It seems to me like 
>> this proposal is based on a misunderstanding of how the API works. The 
>> documentation and/or name should be clarified.
>> 
>> -Joe
>> 
>> > “fixing” this bug will cause programs that once operated on previously 
>> > valid assumptions of “free()” semantics to behave differently, without 
>> > any warnings ever being generated. Conversely incorrect code will 
>> > suddenly become “correct” though this is less of a problem.
>> >
>> >> 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 been fairly diligent about avoiding 
>> >> in Swift's allocation interfaces, and it would be extremely 
>> >> unfortunate for us to backpedal from it.
>> >>
>> >> -Joe
 
 This discussion needs to be grounded by reiterating role of the API. 
 UnsafePointer specifies the memory model without extraneous functionality 
 or convenience.
 
 The UnsafePointer.deallocate() API *is not*:
 
 - a common, expected, or encouraged way to deallocate
 
 - the simplest, safest, or most convenient way to deallocate
 
 - necessarilly the most optimal path for deallocation
>>> 
>>> I don't think this is correct. UnsafePointer.deallocate is the API you must 
>>> use to deallocate memory allocated with UnsafePointer.allocate. My question 
>>> is whether it's acceptable to break all the people who didn't know this and 
>>> are using it to deallocate memory allocated with malloc or new on Apple 
>>> platforms. It sounds like the answer to that is "no, we want to be 
>>> malloc-compatible", and therefore the 'capacity' parameter isn't currently 
>>> serving a purpose today. We will always need to check if the memory is 
>>> actually in the Swift pool before even believing the 'capacity' parameter.
>>> 
>>> (It is definitely true that the intent was for this to be the allocation 
>>> capacity, and I'm surprised you interpreted it as supporting partial 
>>> deallocation. But we probably can't fix that at this point.)
>>> 
>>> Jordan
>>> 
 
 There is only one decision that needs to be made here. Does the Swift 
 runtime track allocation size for manually allocated blocks? I think the 
 answer should be "yes", or at least haven't heard a strong argument 
 against it. UnsafePointer.deallocate() needs to direcly reflect that model 
 by making `allocatedCapacity` an *optional* argument.
 
 Discussion about whether this API is unsafe, misleading, suboptimal or 
 incorrectly implemented are secondary. Those are all deficiencies in the 
 current documentation, current implementation, and availability of 
 higher-level APIs.
 
 Note that yesterday I argued that an optional argument wasn't worth the 
 potential for confusion. That's true from a practical perspective, but I 
 had lost sight of need to clearly specify the memory model. We want the 
 Swift runtime to both have the functionality for tracking block size and 
 also allow user code to track it more efficiently. Both those intentions 
 need to be reflected in this API.
 
 -Andy
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> I mean I would have thought it’s reasonable to expect that if the method 
>> asks for a capacity parameter, it will actually use it 
> 
> It will.
> 
> -Joe

but it doesn’t___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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
> ,
> or the source code
> .
> As far as I can tell the expected behavior is that partial deallocation
> “should” work.
>
> On Thu, Sep 7, 2017 at 8:59 AM, Joe Groff  wrote:
>>
>>
>> The segfaulting example is an incorrect usage. The only valid parameters
>> to deallocate(capacity:) are the base address of an allocation, and the
>> original capacity passed into allocate(); it has never been intended to
>> support partial deallocation of allocated blocks. It seems to me like this
>> proposal is based on a misunderstanding of how the API works. The
>> documentation and/or name should be clarified.
>>
>> -Joe
>>
>> > “fixing” this bug will cause programs that once operated on previously
>> valid assumptions of “free()” semantics to behave differently, without any
>> warnings ever being generated. Conversely incorrect code will suddenly
>> become “correct” though this is less of a problem.
>> >
>> >> 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 been fairly diligent about avoiding in Swift's
>> allocation interfaces, and it would be extremely unfortunate for us to
>> backpedal from it.
>> >>
>> >> -Joe
>>
>
> This discussion needs to be grounded by reiterating role of the API.
> UnsafePointer specifies the memory model without extraneous functionality
> or convenience.
>
> The UnsafePointer.deallocate() API *is not*:
>
> - a common, expected, or encouraged way to deallocate
>
> - the simplest, safest, or most convenient way to deallocate
>
> - necessarilly the most optimal path for deallocation
>
>
> I don't think this is correct. UnsafePointer.deallocate is the API you
> must use to deallocate memory allocated with UnsafePointer.allocate. *My* 
> question
> is whether it's acceptable to break all the people who *didn't* know this
> and are using it to deallocate memory allocated with malloc or new on Apple
> platforms. It sounds like the answer to that is "no, we want to be
> malloc-compatible", and therefore the 'capacity' parameter isn't currently
> serving a purpose today. We will *always* need to check if the memory is
> actually in the Swift pool before even believing the 'capacity' parameter.
>
> (It is definitely true that the *intent* was for this to be the
> allocation capacity, and I'm surprised you interpreted it as supporting
> partial deallocation. But we probably can't fix that at this point.)
>
> Jordan
>
>
> There is only one decision that needs to be made here. Does the Swift
> runtime track allocation size for manually allocated blocks? I think the
> answer should be "yes", or at least haven't heard a strong argument against
> it. UnsafePointer.deallocate() needs to direcly reflect that model by
> making `allocatedCapacity` an *optional* argument.
>
> Discussion about whether this API is unsafe, misleading, suboptimal or
> incorrectly implemented are secondary. Those are all deficiencies in the
> current documentation, current implementation, and availability of
> higher-level APIs.
>
> Note that yesterday I argued that an optional argument wasn't worth the
> potential for confusion. That's true from a practical perspective, but I
> had lost sight of need to clearly specify the memory model. We want the
> Swift runtime to both have the functionality for tracking block size and
> also allow user code to track it more efficiently. Both those intentions
> need to be reflected in this API.
>
> -Andy
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
I mean I would have thought it’s reasonable to expect that if the method
asks for a capacity parameter, it will actually use it
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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

[Taylor Swift via swift-evolution]

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,
> adding the default count could be very misleading. Normally, we try to
> minimize surface area, but adding two methods for the single-value case
> avoids ambiguity between the buffer and pointer semantics:
>
> UMP (pointer)
> --- func initialize(to:count:(=1))
> +++ func initialize(to:)
> +++ func initialize(repeating:count:) // no default count
> +++ func assign(to:)
> +++ func assign(repeating:count:) // no default count
>
> UMRP (raw pointer):
> --- func initializeMemory(as:at:(=0)count:(1)to:)
> +++ func initializeMemory(as:repeating:count:) // remove default count
>
>
> I am *mostly* in favor of this two-method approach, but 'to' may not be
> the right label. Today we have both initialize(to:…) and
> initialize(from:…), which are not opposites. I think we can live with that,
> but we *definitely* can't use assign(to:). "x.assign(to: y)" means some
> form of "y = x".
>
> That said, we don't actually *need* a single-element 'assign' variant,
> because you can also write it "x.pointee = y". But I agree that symmetry is
> nice, if we can get it.
>

assign(to:) was never part of the original proposal, now that you mention
it, it’s stupid and should be left out
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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
> .
> As far as I can tell the expected behavior is that partial deallocation
> “should” work.
>
> On Thu, Sep 7, 2017 at 8:59 AM, Joe Groff  wrote:
>>
>>
>> The segfaulting example is an incorrect usage. The only valid parameters
>> to deallocate(capacity:) are the base address of an allocation, and the
>> original capacity passed into allocate(); it has never been intended to
>> support partial deallocation of allocated blocks. It seems to me like this
>> proposal is based on a misunderstanding of how the API works. The
>> documentation and/or name should be clarified.
>>
>> -Joe
>>
>> > “fixing” this bug will cause programs that once operated on previously
>> valid assumptions of “free()” semantics to behave differently, without any
>> warnings ever being generated. Conversely incorrect code will suddenly
>> become “correct” though this is less of a problem.
>> >
>> >> 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 been fairly diligent about avoiding in Swift's
>> allocation interfaces, and it would be extremely unfortunate for us to
>> backpedal from it.
>> >>
>> >> -Joe
>>
>
> This discussion needs to be grounded by reiterating role of the API.
> UnsafePointer specifies the memory model without extraneous functionality
> or convenience.
>
> The UnsafePointer.deallocate() API *is not*:
>
> - a common, expected, or encouraged way to deallocate
>
> - the simplest, safest, or most convenient way to deallocate
>
> - necessarilly the most optimal path for deallocation
>
> There is only one decision that needs to be made here. Does the Swift
> runtime track allocation size for manually allocated blocks? I think the
> answer should be "yes", or at least haven't heard a strong argument against
> it. UnsafePointer.deallocate() needs to direcly reflect that model by
> making `allocatedCapacity` an *optional* argument.
>
> Discussion about whether this API is unsafe, misleading, suboptimal or
> incorrectly implemented are secondary. Those are all deficiencies in the
> current documentation, current implementation, and availability of
> higher-level APIs.
>
> Note that yesterday I argued that an optional argument wasn't worth the
> potential for confusion. That's true from a practical perspective, but I
> had lost sight of need to clearly specify the memory model. We want the
> Swift runtime to both have the functionality for tracking block size and
> also allow user code to track it more efficiently. Both those intentions
> need to be reflected in this API.
>
> -Andy
>

idk how the swift heap is planned to be implemented, but why is passing the
capacity to deallocate considered the fast path anyway? i thought the block
size was stored in a header right before the block pointer
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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, Joe Groff  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
> .
> As far as I can tell the expected behavior is that partial deallocation
> “should” work.
>
>
> We should fix the documentation bug then.
>
> Another way we could make these APIs easier to use correctly is to
> leverage the type system. allocate could return the allocation size wrapped
> up in an opaque AllocationToken type, and deallocate could take an
> AllocationToken:
>
> static func allocate(capacity: Int) -> (UnsafeMutableBufferPointer,
> AllocationToken)
>
> func deallocate(token: AllocationToken)
>
> That would make it harder for user code to pass an arbitrary size in, and
> make the relationship between the allocate and deallocate calls more
> explicit in their signatures. If we get an ABI break and a bold new idea
> for an allocator design with different context needs in the future, it'd
> also insulate source code from the exact contents of the information that
> needs to be carried from allocation to deallocation.
>
> -Joe
>
> On Thu, Sep 7, 2017 at 8:59 AM, Joe Groff  wrote:
>
>>
>> > On Sep 6, 2017, at 4:46 PM, Taylor Swift  wrote:
>> >
>> >
>> >
>> >> 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 swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>>
>> >>>
>> >>> On Sep 6, 2017, at 1:06 PM, Taylor Swift 
>> wrote:
>> >>>
>> >>>
>> >>>
>>  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 extracting
>> baseAddress! and count. It is very common for the allocation code above to
>> be immediately followed by:
>> 
>>  defer
>> 
>>  {
>>  buffer.
>>  baseAddress?.deallocate(capacity: buffer.count
>>  )
>>  }
>> 
>>  This method is extremely problematic because nearly all users,
>> on first seeing the signature of deallocate(capacity:), will naturally
>> conclude from the capacity label that deallocate(capacity:) is equivalent
>> to some kind of realloc()that can only shrink the buffer. However this is
>> not the actual behavior — deallocate(capacity:) actually ignores the
>> capacity argument and just calls free() on self. The current API is not
>> only awkward and suboptimal, it is misleading. You can write perfectly
>> legal Swift code that shouldn’t segfault, but still can, for example
>> 
>>  var ptr = UnsafeMutablePointer.allocate(capacity: 100
>>  )
>>  ptr.
>>  initialize(to: 13, count: 100
>>  )
>>  ptr.
>>  deallocate(capacity: 50) // deallocate the second half of
>> the memory block
>>  ptr[0] // segmentation fault
>>  where the first 50 addresses should still be valid if the
>> documentation is to be read literally.
>> >>>
>> >>> The fact that the Swift runtime currently uses malloc/free is an
>> implementation detail. Tracking deallocation size is a very useful
>> optimization for better allocator backends, and C++ underwent an ABI break
>> to make it so that sized delete can be supported. Maybe we can change the
>> name to `deallocate(allocatedCapacity:)` to make it clear that it isn't
>> resizing the memory, and/or make the capacity argument optional so that you
>> can pay for the overhead of the allocator deriving the size if it's
>> inconvenient for the calling code to carry the size around, but we
>> shouldn't remove the functionality altogether.
>> >>>
>> >>> -Joe
>> >>> ___
>> >>> swift-evolution mailing list
>> >>> swift-evolution@swift.org
>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>>
>> >>> The idea is to get the house in order by removing all parameters
>> from deallocate(), since that’s what it really does right now. Then, in the
>> future, if Swift gets a more sophisticated allocato

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

[Taylor Swift via swift-evolution]

I don’t see any source for this claim in the documentation
,
or the source code
.
As far as I can tell the expected behavior is that partial deallocation
“should” work.

On Thu, Sep 7, 2017 at 8:59 AM, Joe Groff  wrote:

>
> > On Sep 6, 2017, at 4:46 PM, Taylor Swift  wrote:
> >
> >
> >
> >> 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 swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>>
> >>> On Sep 6, 2017, at 1:06 PM, Taylor Swift 
> wrote:
> >>>
> >>>
> >>>
>  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 extracting
> baseAddress! and count. It is very common for the allocation code above to
> be immediately followed by:
> 
>  defer
> 
>  {
>  buffer.
>  baseAddress?.deallocate(capacity: buffer.count
>  )
>  }
> 
>  This method is extremely problematic because nearly all users, on
> first seeing the signature of deallocate(capacity:), will naturally
> conclude from the capacity label that deallocate(capacity:) is equivalent
> to some kind of realloc()that can only shrink the buffer. However this is
> not the actual behavior — deallocate(capacity:) actually ignores the
> capacity argument and just calls free() on self. The current API is not
> only awkward and suboptimal, it is misleading. You can write perfectly
> legal Swift code that shouldn’t segfault, but still can, for example
> 
>  var ptr = UnsafeMutablePointer.allocate(capacity: 100
>  )
>  ptr.
>  initialize(to: 13, count: 100
>  )
>  ptr.
>  deallocate(capacity: 50) // deallocate the second half of the
> memory block
>  ptr[0] // segmentation fault
>  where the first 50 addresses should still be valid if the
> documentation is to be read literally.
> >>>
> >>> The fact that the Swift runtime currently uses malloc/free is an
> implementation detail. Tracking deallocation size is a very useful
> optimization for better allocator backends, and C++ underwent an ABI break
> to make it so that sized delete can be supported. Maybe we can change the
> name to `deallocate(allocatedCapacity:)` to make it clear that it isn't
> resizing the memory, and/or make the capacity argument optional so that you
> can pay for the overhead of the allocator deriving the size if it's
> inconvenient for the calling code to carry the size around, but we
> shouldn't remove the functionality altogether.
> >>>
> >>> -Joe
> >>> ___
> >>> swift-evolution mailing list
> >>> swift-evolution@swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>
> >>> The idea is to get the house in order by removing all parameters
> from deallocate(), since that’s what it really does right now. Then, in the
> future, if Swift gets a more sophisticated allocator backend, a new method
> like deallocate(capacity:) or reallocate(toCapacity:) could be added
> without conflicting with the currently named deallocate(capacity:).
> However, using the function signature to pretend that it does something it
> can’t actually do right now is extremely dangerous.
> >>
> >> I don't think that's a good idea in this case, because it's not
> unlikely we would explore an optimized allocator soon after ABI stability,
> and retrofitting these interfaces in a future version of Swift would put a
> deployment target limit on when they can be used, and mean that a lot of
> user code would need to be retrofitted to carry allocated capacities where
> needed to see any benefit.
> >>
> >> -Joe
> >
> > The fact that we’re using malloc and free is already part of the ABI
> because old libraries need to be able to deallocate memory allocated by
> newer libraries.
> 
>  The compiler doesn't ever generate calls directly to malloc and free,
> and the runtime entry points we do use already take size and alignment on
> both allocation and deallocation.
> 
> > Within the standard library we could make use of some new
> deallocation fast path in the future without worrying about backward
> deployment.
> >
> > Outside of the standard library, clients will ge

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

[Taylor Swift via swift-evolution]

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 `atByteOffset:` and will only appear in
UnsafeMutableRawBufferPointer. “at:” arguments are no longer needed in
UnsafeMutableRawPointer, since we can just use pointer arithmetic now.


*3*. move UnsafeMutableBufferPointer’s `at:` arguments to the front of the
parameter list. mostly cause any pointer arithmetic happens in the front so
structurally we want to mirror that.

*4*. add dual (to:) single element initializers and assigners to
UnsafeMutablePointer, but not UnsafeMutableRawPointer because it’s
apparently not useful there.
`UnsafeMutableRawPointer.initializeMemory(as:repeating:count:)` still
loses its default count to prevent confusion with its buffer variant.

*5*. memory deallocation on buffer pointers is clearly documented to only
be defined behavior when the buffer matches a whole heap block.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

> 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 agree with that?
>> 
>> this could be problematic if you have multiple contiguous buffers carved out 
>> of the same heap block. i agree that this is the best semantics for buffer 
>> pointers but we need the sized backend in Swift before this is possible else 
>> we will end up in the same boat we’re in right now with 
>> `deallocate(capacity:)` where we would have to make buffer deallocate heap 
>> block-based for now and then pull the rug out from underneath users later in 
>> order to switch to the improved semantics
> 
> If I understand your proposal, it’s only valid to deallocate a buffer that 
> was allocated with the same capacity. Anything else should assert.
> -Andy

the proposal isn’t specific enough there and that’s my fault but this seems 
like a good solution. in the future if we get a sized backend we can loosen the 
assertions and make the partial heap block buffer case defined behavior.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

> 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 been fairly diligent about avoiding in Swift's 
>>> allocation interfaces, and it would be extremely unfortunate for us to 
>>> backpedal from it.
>>> 
>>> -Joe
>> 
>> Which is worse, an active gaping hole in Swift’s memory system, or 
>> potentially discouraging users from using a hypothetical future allocation 
>> API? 
>> 
>> Making sure the existing allocation API is working properly is a 
>> prerequisite to introducing a future more advanced allocation API.
> 
> I think we agree that the runtime should assert when it is passed an invalid 
> deallocation size. The problem you’re describing could still occur with the 
> UnsafeBufferPointer.deallocate() method if the user happened to slice and 
> rebase the buffer.
> 
> -Andy 

the proposal specifically defines UnsafeMutableBufferPointer.deallocate() 
behavior in terms of calling deallocate() on its baseAddress if non-nil. this 
operation doesn’t have any relation to the length of the buffer itself. that 
being said, it *should*, and i’d be down for redefining it in terms of 
deallocating self.count elements, if this was technically possible but it’s not___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

> 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 already part of the ABI 
> because old libraries need to be able to deallocate memory allocated by 
> newer libraries.
 
 The compiler doesn't ever generate calls directly to malloc and free, and 
 the runtime entry points we do use already take size and alignment on both 
 allocation and deallocation.
>>> 
>>> True, we’ve never said that UnsafePointer deallocation is compatible with 
>>> C, and I we don't currently expose malloc_size functionality in any API 
>>> AFAIK.
>>> 
> Within the standard library we could make use of some new deallocation 
> fast path in the future without worrying about backward deployment.
> 
> Outside of the standard library, clients will get the benefits of 
> whatever allocator is available on their deployed platform because we now 
> encourage them to use UnsafeBufferPointer.deallocate(). We can change the 
> implementation inside UnsafeBufferPointer all we want, as long as it’s 
> still malloc-compatible.
> 
> I’m sure we’ll want to provide a better allocation/deallocation API in 
> the future for systems programmers based on move-only types. That will 
> already be deployment-limited.
> 
> Absolute worst case, we introduce a sized UnsafePointer.deallocate in the 
> future. Any new code outside the stdlib that wants the performance 
> advantage would either need to
> - trivially wrap deallocation using UnsafeBufferPointer
> - create a trivial UnsafePointer.deallocate thunk under an availability 
> flag
 
 Since we already have sized deallocate, why would we take it away? If the 
 name is misleading, we can change the name.
>>> 
>>> I don't think leaving it as an optional argument is worthwhile, as I 
>>> explained above. Deallocation capacity is either required or we drop it 
>>> completely. If we keep it, then `allocatedCapacity` is the right name.
>>> 
>>> The reason for taking it away, beside being misleading, is that it exposes 
>>> another level of unsafety.
>>> 
>>> My thinking has been that this is not the allocation fast path of the 
>>> future, and the stdlib itself could track the size of unsafely-allocated 
>>> blocks if it ever used a different underlying allocator.
>>> 
>>> Now I realize this isn't really about fast/slow deallocation paths. 
>>> Removing `capacity` or even making it optional forces all future Swift 
>>> implementations to provide malloc_size functionality for any piece of 
>>> memory that is compatible with the Unsafe API.
>>> 
>>> I'm actually ok with that, because I think it's generally desirable for 
>>> application memory to reside in either in malloc-compatible blocks or fixed 
>>> size pools. i.e. I think malloc_size is something the platform needs. 
>>> However, you seem to think this would be too restrictive in the future. How 
>>> is this a known problem for C and what's your confidence level it will be a 
>>> problem for Swift?
>> 
>> No, I agree that being malloc-compatible is a reasonable goal; on Apple 
>> platforms, being able to register any custom allocator we come up with as a 
>> malloc zone would mean that the platform's existing memory profiling and 
>> debugging tools can still work. Even if we have a scheme where the allocator 
>> directly reaches into per-thread fixed-sized pools, it seems to me like it'd 
>> be hard to make malloc_size impossible to implement, though it might be 
>> slow, asking each pool for each thread whether an address is inside it. 
>> Strongly encouraging, if not requiring, user code to provide deallocation 
>> sizes seems to me like a prerequisite to making that sort of design a net 
>> win over plain malloc/free. 
>> 
>> -Joe
> 
> Ok good. For growable buffers, we also want the OS to give us malloc_size 
> which may be larger than requested capacity.
> 
> 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 agree with that?

this could be problematic if you have multiple contiguous buffers carved out of 
the same heap block. i agree that this is the best semantics for buffer 
pointers but we need the sized backend in Swift before this is possible else we 
will end up in the same boat we’re in right now with `deallocate(capacity:)` 
where we would have to make buffer deallocate heap block-based for now and then 
pull the rug out from underneath users later in order to switch to the improved 
semantics

> 
> Any future safe API for manual buffer allocation/deallocation will also track 
> the buffer size, so that will also be the fast path.
> 
> In the future, pointer.deallocate() wit

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

[Taylor Swift via swift-evolution]

> 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 swift-evolution 
>>  wrote:
>> 
>> 
>> On Sep 6, 2017, at 1:06 PM, Taylor Swift  wrote:
>> 
>> 
>> 
>>> On Wed, Sep 6, 2017 at 12:41 PM, Joe Groff via swift-evolution 
>>>  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 
>>> extracting baseAddress! and count. It is very common for the allocation 
>>> code above to be immediately followed by:
>>> 
>>> defer
>>> 
>>> {
>>> buffer.
>>> baseAddress?.deallocate(capacity: buffer.count
>>> )
>>> }
>>> 
>>> This method is extremely problematic because nearly all users, on first 
>>> seeing the signature of deallocate(capacity:), will naturally conclude 
>>> from the capacity label that deallocate(capacity:) is equivalent to 
>>> some kind of realloc()that can only shrink the buffer. However this is 
>>> not the actual behavior — deallocate(capacity:) actually ignores the 
>>> capacity argument and just calls free() on self. The current API is not 
>>> only awkward and suboptimal, it is misleading. You can write perfectly 
>>> legal Swift code that shouldn’t segfault, but still can, for example
>>> 
>>> var ptr = UnsafeMutablePointer.allocate(capacity: 100
>>> )
>>> ptr.
>>> initialize(to: 13, count: 100
>>> )
>>> ptr.
>>> deallocate(capacity: 50) // deallocate the second half of the 
>>> memory block
>>> ptr[0] // segmentation fault
>>> where the first 50 addresses should still be valid if the 
>>> documentation is to be read literally.
>> 
>> The fact that the Swift runtime currently uses malloc/free is an 
>> implementation detail. Tracking deallocation size is a very useful 
>> optimization for better allocator backends, and C++ underwent an ABI 
>> break to make it so that sized delete can be supported. Maybe we can 
>> change the name to `deallocate(allocatedCapacity:)` to make it clear 
>> that it isn't resizing the memory, and/or make the capacity argument 
>> optional so that you can pay for the overhead of the allocator deriving 
>> the size if it's inconvenient for the calling code to carry the size 
>> around, but we shouldn't remove the functionality altogether.
>> 
>> -Joe
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> The idea is to get the house in order by removing all parameters from 
>> deallocate(), since that’s what it really does right now. Then, in the 
>> future, if Swift gets a more sophisticated allocator backend, a new 
>> method like deallocate(capacity:) or reallocate(toCapacity:) could be 
>> added without conflicting with the currently named 
>> deallocate(capacity:). However, using the function signature to pretend 
>> that it does something it can’t actually do right now is extremely 
>> dangerous.
> 
> I don't think that's a good idea in this case, because it's not unlikely 
> we would explore an optimized allocator soon after ABI stability, and 
> retrofitting these interfaces in a future version of Swift would put a 
> deployment target limit on when they can be used, and mean that a lot of 
> user code would need to be retrofitted to carry allocated capacities 
> where needed to see any benefit.
> 
> -Joe
 
 The fact that we’re using malloc and free is already part of the ABI 
 because old libraries need to be able to deallocate memory allocated by 
 newer libraries.
>>> 
>>> The compiler doesn't ever generate calls directly to malloc and free, and 
>>> the runtime entry points we do use already take size and alignment on both 
>>> allocation and deallocation.
>>> 
 Within the standard library we could make use of some new deallocation 
 fast path in the future without worrying about backward deployment.
 
 Outside of the standard library, clients will get the benefits of whatever 
 allocator is available on their deployed platform because we now encourage 
 them to use UnsafeBufferPointer.deallocate(). We can change the 
 implementation inside UnsafeBufferPointer all we want, as long as it’s 
 still malloc-compatible.
 
 I’m sure we’ll want to provide a better allocation/deallocation API in the 
 future for systems programmers based on move-only types. That will already 

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

[Taylor Swift via swift-evolution]

> 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, 2017 at 12:41 PM, Joe Groff via swift-evolution 
>  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 extracting 
> baseAddress! and count. It is very common for the allocation code above 
> to be immediately followed by:
> 
> defer
> 
> {
>   buffer.
> baseAddress?.deallocate(capacity: buffer.count
> )
> }
> 
> This method is extremely problematic because nearly all users, on first 
> seeing the signature of deallocate(capacity:), will naturally conclude 
> from the capacity label that deallocate(capacity:) is equivalent to some 
> kind of realloc()that can only shrink the buffer. However this is not the 
> actual behavior — deallocate(capacity:) actually ignores the capacity 
> argument and just calls free() on self. The current API is not only 
> awkward and suboptimal, it is misleading. You can write perfectly legal 
> Swift code that shouldn’t segfault, but still can, for example
> 
> var ptr = UnsafeMutablePointer.allocate(capacity: 100
> )
> ptr.
> initialize(to: 13, count: 100
> )
> ptr.
> deallocate(capacity: 50) // deallocate the second half of the memory 
> block
> ptr[0] // segmentation fault
> where the first 50 addresses should still be valid if the 
> documentation is to be read literally.
 
 The fact that the Swift runtime currently uses malloc/free is an 
 implementation detail. Tracking deallocation size is a very useful 
 optimization for better allocator backends, and C++ underwent an ABI break 
 to make it so that sized delete can be supported. Maybe we can change the 
 name to `deallocate(allocatedCapacity:)` to make it clear that it isn't 
 resizing the memory, and/or make the capacity argument optional so that 
 you can pay for the overhead of the allocator deriving the size if it's 
 inconvenient for the calling code to carry the size around, but we 
 shouldn't remove the functionality altogether.
 
 -Joe
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
 
 The idea is to get the house in order by removing all parameters from 
 deallocate(), since that’s what it really does right now. Then, in the 
 future, if Swift gets a more sophisticated allocator backend, a new method 
 like deallocate(capacity:) or reallocate(toCapacity:) could be added 
 without conflicting with the currently named deallocate(capacity:). 
 However, using the function signature to pretend that it does something it 
 can’t actually do right now is extremely dangerous.
>>> 
>>> I don't think that's a good idea in this case, because it's not unlikely we 
>>> would explore an optimized allocator soon after ABI stability, and 
>>> retrofitting these interfaces in a future version of Swift would put a 
>>> deployment target limit on when they can be used, and mean that a lot of 
>>> user code would need to be retrofitted to carry allocated capacities where 
>>> needed to see any benefit.
>>> 
>>> -Joe
>> 
>> The fact that we’re using malloc and free is already part of the ABI because 
>> old libraries need to be able to deallocate memory allocated by newer 
>> libraries.
> 
> The compiler doesn't ever generate calls directly to malloc and free, and the 
> runtime entry points we do use already take size and alignment on both 
> allocation and deallocation.
> 
>> Within the standard library we could make use of some new deallocation fast 
>> path in the future without worrying about backward deployment.
>> 
>> Outside of the standard library, clients will get the benefits of whatever 
>> allocator is available on their deployed platform because we now encourage 
>> them to use UnsafeBufferPointer.deallocate(). We can change the 
>> implementation inside UnsafeBufferPointer all we want, as long as it’s still 
>> malloc-compatible.
>> 
>> I’m sure we’ll want to provide a better allocation/deallocation API in the 
>> future for systems programmers based on move-only types. That will already 
>> be deployment-limited.
>> 
>> Absolute worst case, we introduce a sized UnsafePointer.deallocate in the 
>> future. Any new code outside the stdlib that wants the performance advantage 
>> would either need to
>> - trivially wrap deallocation using UnsafeBufferPointer
>> - create a trivial UnsafePointer.deallocate thunk unde

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

[Taylor Swift via swift-evolution]

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 extracting
> baseAddress! and count. It is very common for the allocation code above to
> be immediately followed by:
> >
> > defer
> >
> > {
> > buffer.
> > baseAddress?.deallocate(capacity: buffer.count
> > )
> > }
> >
> > This method is extremely problematic because nearly all users, on first
> seeing the signature of deallocate(capacity:), will naturally conclude from
> the capacity label that deallocate(capacity:) is equivalent to some kind of
> realloc()that can only shrink the buffer. However this is not the actual
> behavior — deallocate(capacity:) actually ignores the capacity argument and
> just calls free() on self. The current API is not only awkward and
> suboptimal, it is misleading. You can write perfectly legal Swift code that
> shouldn’t segfault, but still can, for example
> >
> > var ptr = UnsafeMutablePointer.allocate(capacity: 100
> > )
> > ptr.
> > initialize(to: 13, count: 100
> > )
> > ptr.
> > deallocate(capacity: 50) // deallocate the second half of the memory
> block
> > ptr[0] // segmentation fault
> > where the first 50 addresses should still be valid if the
> documentation is to be read literally.
>
> The fact that the Swift runtime currently uses malloc/free is an
> implementation detail. Tracking deallocation size is a very useful
> optimization for better allocator backends, and C++ underwent an ABI break
> to make it so that sized delete can be supported. Maybe we can change the
> name to `deallocate(allocatedCapacity:)` to make it clear that it isn't
> resizing the memory, and/or make the capacity argument optional so that you
> can pay for the overhead of the allocator deriving the size if it's
> inconvenient for the calling code to carry the size around, but we
> shouldn't remove the functionality altogether.
>
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

The idea is to get the house in order by removing all parameters from
deallocate(), since that’s what it really does right now. Then, in the
future, if Swift gets a more sophisticated allocator backend, a new method
like deallocate(capacity:) or reallocate(toCapacity:) could be added
without conflicting with the currently named deallocate(capacity:).
However, using the function signature to pretend that it does something it
can’t actually do right now is extremely dangerous.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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

[Taylor Swift via swift-evolution]

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 explicit "offset" label. The call site will
>>> be just as explicit as dropping down to `baseAddress` but without any
>>> pointer conversion boilerplate.
>>>
>>> UMRBP (raw buffer):
>>> +++ func initializeMemory(atByteOffset:as:from:)
>>> +++ func moveInitializeMemory(atByteOffset:as:from:)
>>>
>>>
>> Agree, but the label should just be `atByte:`, not `atByteOffset:`.
>> after all, we don’t use `atOffset:` in the strided case; its obvious
>> that it’s an offset
>>
>
> The existing APIs use the terminology "byte offset"--for example,
> URP.load(fromByteOffset:as:). The rationale is that "at" without a noun
> that follows implies, per Swift API naming guidelines, "at index." If you
> want to specify, as we do here, what the index _is_, then it's written out
> in full.
>
>
> Yes, it seems overly cumbersome, but I was following existing conventions
> which were intentionally very explicit.
>

it’s visually cumbersome because the “atByteOffset” overwhelms the other
two arguments but I guess i could live with it.


>
>>> We don't have a consensus, but I think the suggestion to distinguish
>>> between single value vs. multiple semantics was good. Otherwise,
>>> adding the default count could be very misleading. Normally, we try to
>>> minimize surface area, but adding two methods for the single-value case
>>> avoids ambiguity between the buffer and pointer semantics:
>>>
>>> UMP (pointer)
>>> --- func initialize(to:count:(=1))
>>> +++ func initialize(to:)
>>> +++ func initialize(repeating:count:) // no default count
>>> +++ func assign(to:)
>>> +++ func assign(repeating:count:) // no default count
>>>
>>> UMRP (raw pointer):
>>> --- func initializeMemory(as:at:(=0)count:(1)to:)
>>> +++ func initializeMemory(as:repeating:count:) // remove default
>>> count
>>>
>>
>> still extremely suspicious of this but i’m willing to compromise. also
>> there should be an `initializeMemory(at:to:)` to match the typed
>> methods
>>
>
> Do you mean initializeMemory(as:to:)?
>
>
> I don’t think it’s necessary since raw buffers are not normally used to
> hold a single typed element. We don’t need symmetry between raw and typed
> pointers and I wouldn’t want to add an API that will never be used. So, I
> would be ok with it only if there’s some use case that I’m overlooking.
>

The only case i can think of is initializing a buffer header but then again
i rarely use raw pointers so i’m not sure how much this feature would be
used. However, this function is already

in the API (with a default count of 1 and offset of 0) so there’s that.


>
> -Andy
>
>
>>> On Tue, Sep 5, 2017 at 11:31 AM, Andrew Trick  wrote:
>>>
 I think we’ve agreed to a few minor updates to this proposal. Since
 there hasn’t been any other feedback on the thread it may be worth posting
 an amended proposal so we all know what we’ve agreed on.

 -Andy

 On Sep 3, 2017, at 8:23 PM, Andrew Trick via swift-evolution <
 swift-evolution@swift.org> 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 pointer arithmetic can be used instead
> (just like with UnsafeMutablePointer).
>

 I agree that it seems quite sensible to remove the ‘at’ parameter
 altogether from the UMRP method.


 No code in tree or on github is using the `at` argument. I think it can
 be removed. A fixit should still be possible.

 Not convinced moving the at: argument to come before the as: argument
> is worth it in terms of source breakage.
>

 Since much of this proposal involves shuffling and relabeling
 arguments, I’d argue it’s better to break slight more source in one go for
 the optimal API than to break slightly less for a slightly less optimal
 API, no? (This is assuming there is agreement that ‘at:as:’ is less prone
 to misinterpretation than ‘as:at:’.)


 To be clear, we’re just talking about 
 UnsafeMutableRawBufferPointer.initializeMemory
 now, so this is purely additive.
 I think the label needs to be `atByteOffset`, and placing it before
 `as` makes a lot of sense because it no longer depends on the type’s
 stride.

 -Andy
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution


>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swi

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

[Taylor Swift via swift-evolution]

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 need a byteOffset: argument.
>> I’m also still not comfortable with duplicating functionality for the sake
>> of having two names
>>
>>
>> I’ll summarize what I think happened in this thread...
>>
>> I don't think the suggested copyBytes rename was controversial:
>>
>> UMRP (raw pointer):
>> --- copyBytes(from:count)
>> +++ copyMemory(from:bytes:)
>>
>>
>> UMRBP (raw buffer):
>> --- copyBytes(from:)
>> +++ copyMemory(atByteOffset:from:)
>>
>> --- copyBytes(from:)
>> +++ copyMemory(from:)
>>
>>
> no problem with this
>
>
>>
>> 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 explicit "offset" label. The call site will
>> be just as explicit as dropping down to `baseAddress` but without any
>> pointer conversion boilerplate.
>>
>> UMRBP (raw buffer):
>> +++ func initializeMemory(atByteOffset:as:from:)
>> +++ func moveInitializeMemory(atByteOffset:as:from:)
>>
>>
> Agree, but the label should just be `atByte:`, not `atByteOffset:`. after
> all, we don’t use `atOffset:` in the strided case; its obvious that it’s
> an offset
>
>
>>
>> Than, in the one existing initializeMemory method, just drop the strided
>> index.
>> It's never used, we want to be consistent in using a byte offset
>> for the raw index, and that can be expressed just as easily as pointer
>> arithmetic:
>>
>> UMRP (raw pointer):
>> --- func initializeMemory(as:T.Type, at:Int = 0, count:Int = 1, to:T)
>> +++ func initializeMemory(as:T.Type, repeating:T, count:Int = 1)
>>
>> Then you can simply leave these methods as-is:
>> > func initializeMemory(as:T.Type, from:UnsafePointer, count:Int)
>> > func moveInitializeMemory(as:T.Type, from:UnsafeMutablePointer,
>> count:Int)
>>
>>
> yes
>
>
>> We don't have a consensus, but I think the suggestion to distinguish
>> between single value vs. multiple semantics was good. Otherwise,
>> adding the default count could be very misleading. Normally, we try to
>> minimize surface area, but adding two methods for the single-value case
>> avoids ambiguity between the buffer and pointer semantics:
>>
>> UMP (pointer)
>> --- func initialize(to:count:(=1))
>> +++ func initialize(to:)
>> +++ func initialize(repeating:count:) // no default count
>> +++ func assign(to:)
>> +++ func assign(repeating:count:) // no default count
>>
>> UMRP (raw pointer):
>> --- func initializeMemory(as:at:(=0)count:(1)to:)
>> +++ func initializeMemory(as:repeating:count:) // remove default
>> count
>>
>
> still extremely suspicious of this but i’m willing to compromise. also
> there should be an `initializeMemory(at:to:)` to match the typed
> methods
>

*initializeMemory(as:to:)


>
>
>>
>> -Andy
>>
>> On Tue, Sep 5, 2017 at 11:31 AM, Andrew Trick  wrote:
>>
>>> I think we’ve agreed to a few minor updates to this proposal. Since
>>> there hasn’t been any other feedback on the thread it may be worth posting
>>> an amended proposal so we all know what we’ve agreed on.
>>>
>>> -Andy
>>>
>>> On Sep 3, 2017, at 8:23 PM, Andrew Trick via swift-evolution <
>>> swift-evolution@swift.org> 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 pointer arithmetic can be used instead (just
 like with UnsafeMutablePointer).

>>>
>>> I agree that it seems quite sensible to remove the ‘at’ parameter
>>> altogether from the UMRP method.
>>>
>>>
>>> No code in tree or on github is using the `at` argument. I think it can
>>> be removed. A fixit should still be possible.
>>>
>>> Not convinced moving the at: argument to come before the as: argument
 is worth it in terms of source breakage.

>>>
>>> Since much of this proposal involves shuffling and relabeling arguments,
>>> I’d argue it’s better to break slight more source in one go for the optimal
>>> API than to break slightly less for a slightly less optimal API, no? (This
>>> is assuming there is agreement that ‘at:as:’ is less prone to
>>> misinterpretation than ‘as:at:’.)
>>>
>>>
>>> To be clear, we’re just talking about 
>>> UnsafeMutableRawBufferPointer.initializeMemory
>>> now, so this is purely additive.
>>> I think the label needs to be `atByteOffset`, and placing it before `as`
>>> makes a lot of sense because it no longer depends on the type’s stride.
>>>
>>> -Andy
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/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

[Taylor Swift via swift-evolution]

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 duplicating functionality for the sake
> of having two names
>
>
> I’ll summarize what I think happened in this thread...
>
> I don't think the suggested copyBytes rename was controversial:
>
> UMRP (raw pointer):
> --- copyBytes(from:count)
> +++ copyMemory(from:bytes:)
>
>
> UMRBP (raw buffer):
> --- copyBytes(from:)
> +++ copyMemory(atByteOffset:from:)
>
> --- copyBytes(from:)
> +++ copyMemory(from:)
>
>
no problem with this


>
> 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 explicit "offset" label. The call site will
> be just as explicit as dropping down to `baseAddress` but without any
> pointer conversion boilerplate.
>
> UMRBP (raw buffer):
> +++ func initializeMemory(atByteOffset:as:from:)
> +++ func moveInitializeMemory(atByteOffset:as:from:)
>
>
Agree, but the label should just be `atByte:`, not `atByteOffset:`. after
all, we don’t use `atOffset:` in the strided case; its obvious that it’s an
offset


>
> Than, in the one existing initializeMemory method, just drop the strided
> index.
> It's never used, we want to be consistent in using a byte offset
> for the raw index, and that can be expressed just as easily as pointer
> arithmetic:
>
> UMRP (raw pointer):
> --- func initializeMemory(as:T.Type, at:Int = 0, count:Int = 1, to:T)
> +++ func initializeMemory(as:T.Type, repeating:T, count:Int = 1)
>
> Then you can simply leave these methods as-is:
> > func initializeMemory(as:T.Type, from:UnsafePointer, count:Int)
> > func moveInitializeMemory(as:T.Type, from:UnsafeMutablePointer,
> count:Int)
>
>
yes


> We don't have a consensus, but I think the suggestion to distinguish
> between single value vs. multiple semantics was good. Otherwise,
> adding the default count could be very misleading. Normally, we try to
> minimize surface area, but adding two methods for the single-value case
> avoids ambiguity between the buffer and pointer semantics:
>
> UMP (pointer)
> --- func initialize(to:count:(=1))
> +++ func initialize(to:)
> +++ func initialize(repeating:count:) // no default count
> +++ func assign(to:)
> +++ func assign(repeating:count:) // no default count
>
> UMRP (raw pointer):
> --- func initializeMemory(as:at:(=0)count:(1)to:)
> +++ func initializeMemory(as:repeating:count:) // remove default count
>

still extremely suspicious of this but i’m willing to compromise. also
there should be an `initializeMemory(at:to:)` to match the typed methods


>
> -Andy
>
> On Tue, Sep 5, 2017 at 11:31 AM, Andrew Trick  wrote:
>
>> I think we’ve agreed to a few minor updates to this proposal. Since there
>> hasn’t been any other feedback on the thread it may be worth posting an
>> amended proposal so we all know what we’ve agreed on.
>>
>> -Andy
>>
>> On Sep 3, 2017, at 8:23 PM, Andrew Trick via swift-evolution <
>> swift-evolution@swift.org> 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 pointer arithmetic can be used instead (just
>>> like with UnsafeMutablePointer).
>>>
>>
>> I agree that it seems quite sensible to remove the ‘at’ parameter
>> altogether from the UMRP method.
>>
>>
>> No code in tree or on github is using the `at` argument. I think it can
>> be removed. A fixit should still be possible.
>>
>> Not convinced moving the at: argument to come before the as: argument is
>>> worth it in terms of source breakage.
>>>
>>
>> Since much of this proposal involves shuffling and relabeling arguments,
>> I’d argue it’s better to break slight more source in one go for the optimal
>> API than to break slightly less for a slightly less optimal API, no? (This
>> is assuming there is agreement that ‘at:as:’ is less prone to
>> misinterpretation than ‘as:at:’.)
>>
>>
>> To be clear, we’re just talking about 
>> UnsafeMutableRawBufferPointer.initializeMemory
>> now, so this is purely additive.
>> I think the label needs to be `atByteOffset`, and placing it before `as`
>> makes a lot of sense because it no longer depends on the type’s stride.
>>
>> -Andy
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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

[Taylor Swift via swift-evolution]

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 few minor updates to this proposal. Since there
> hasn’t been any other feedback on the thread it may be worth posting an
> amended proposal so we all know what we’ve agreed on.
>
> -Andy
>
> On Sep 3, 2017, at 8:23 PM, Andrew Trick via swift-evolution <
> swift-evolution@swift.org> 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 pointer arithmetic can be used instead (just
>> like with UnsafeMutablePointer).
>>
>
> I agree that it seems quite sensible to remove the ‘at’ parameter
> altogether from the UMRP method.
>
>
> No code in tree or on github is using the `at` argument. I think it can be
> removed. A fixit should still be possible.
>
> Not convinced moving the at: argument to come before the as: argument is
>> worth it in terms of source breakage.
>>
>
> Since much of this proposal involves shuffling and relabeling arguments,
> I’d argue it’s better to break slight more source in one go for the optimal
> API than to break slightly less for a slightly less optimal API, no? (This
> is assuming there is agreement that ‘at:as:’ is less prone to
> misinterpretation than ‘as:at:’.)
>
>
> To be clear, we’re just talking about 
> UnsafeMutableRawBufferPointer.initializeMemory
> now, so this is purely additive.
> I think the label needs to be `atByteOffset`, and placing it before `as`
> makes a lot of sense because it no longer depends on the type’s stride.
>
> -Andy
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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

[Taylor Swift via swift-evolution]

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 pointer arithmetic can be used instead (just like 
>>> with UnsafeMutablePointer).
>> 
>> I agree that it seems quite sensible to remove the ‘at’ parameter altogether 
>> from the UMRP method.
> 
> No code in tree or on github is using the `at` argument. I think it can be 
> removed. A fixit should still be possible.
> 
>>> Not convinced moving the at: argument to come before the as: argument is 
>>> worth it in terms of source breakage.
>> 
>> Since much of this proposal involves shuffling and relabeling arguments, I’d 
>> argue it’s better to break slight more source in one go for the optimal API 
>> than to break slightly less for a slightly less optimal API, no? (This is 
>> assuming there is agreement that ‘at:as:’ is less prone to misinterpretation 
>> than ‘as:at:’.)
> 
> 
> To be clear, we’re just talking about 
> UnsafeMutableRawBufferPointer.initializeMemory now, so this is purely 
> additive.
> I think the label needs to be `atByteOffset`, and placing it before `as` 
> makes a lot of sense because it no longer depends on the type’s stride. 
> 
> -Andy
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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

[Taylor Swift via swift-evolution]

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> wrote:
>>
>> the subscript doesn’t know about the stride that you want to use. If you
>>>> want to get rid of the `at:` ambiguity, you have to get rid of it
>>>> everywhere, or users will just wind up having to remember two ways (one
>>>> ambiguous and one less ambiguous) of doing the same thing, instead of one
>>>> (ambiguous) way of doing it.
>>>>
>>>
>>> Certainly, that's a good point. On rethink and another re-reading of the
>>> proposal, it's unclear to me that the addition of `at` arguments to
>>> UnsafeMutablePointer is sufficiently justified by the proposal text. Is it
>>> merely that it's shorter than writing `foo + MemoryLayout.stride *
>>> offset`? With the ambiguity of `at`, it seems that the current way of
>>> writing it, though longer, is certainly less ambiguous.
>>>
>>
>> Please reread it; UnsafeMutablePointer’s methods do *not* use `at:`.
>>
>>
>> Regarding the typed buffer pointers, I think it is clear by convention,
>> and will be well documented, that the `at` label refers to a position in
>> `self`.
>>
>> The raw buffer pointer API isn’t so obvious. Since the `at` refers to
>> `self` it might more logically be a byte offset. Note that `at` as a label
>> name always refers to a strided index.
>>
>> This would be a bit more explicit:
>> UnsafeRawBufferPointer.initializeMemory(as:T.self, atByteOffset:
>> position * MemoryLayout.stride, from: bufferOfT)
>>
>> But possibly less convenient… Since that `at` label currently on
>> UnsafeRawPointer.initializeMemory is almost never used, I don’t think we
>> need to worry too much about convenience.
>>
>> That existing `at` label on UnsafeRawPointer.initializeMemory, would
>> also need to be renamed, which is fine.
>>
>
> If I may suggest one more incremental improvement in clarity, it would be
> to move `at[ByteOffset]` to be the first argument; this eliminates the
> possible reading that we are offsetting the source buffer:
>
> ```
> UnsafeRawBufferPointer.initializeMemory(atByteOffset: position *
> MemoryLayout.stride, as:T.self, from: bufferOfT)
> ```
>
>
> Sure, that probably makes sense if we decide to go with a byte offset vs.
> stride index.
> -Andy
>

If we use byte offset, then the at parameter in UnsafeMutableRawPointer
should be removed, since pointer arithmetic can be used instead (just like
with UnsafeMutablePointer). Not convinced moving the at: argument to come
before the as: argument is worth it in terms of source breakage.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/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

[Taylor Swift via swift-evolution]

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 <
>>> swift-evolution@swift.org> wrote:
>>>
 Hello Swift community,

 The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointer: add
 missing methods, adjust existing labels for clarity, and remove
 deallocation size" begins now and runs through September 7, 2017. The
 proposal is available here:

 https://github.com/apple/swift-evolution/blob/master/proposa
 ls/0184-unsafe-pointers-add-missing.md

 Reviews are an important part of the Swift evolution process. All
 reviews should be sent to the swift-evolution mailing list at

 https://lists.swift.org/mailman/listinfo/swift-evolution

 or, if you would like to keep your feedback private, directly to the
 review manager. When replying, please try to keep the proposal link at the
 top of the message:

 Proposal link:

 https://github.com/apple/swift-evolution/blob/master/proposa
 ls/0184-unsafe-pointers-add-missing.md

 Reply text

 Other replies


 What
 goes into a review?

 The goal of the review process is to improve the proposal under review
 through constructive criticism and, eventually, determine the direction of
 Swift. When writing your review, here are some questions you might want to
 answer in your review:

- What is your evaluation of the proposal?

 Overall, this is an improvement. However, I do have some questions and
>>> concerns:
>>>
>>>
>>> Questions:
>>>
>>> ## UnsafeMutableRawPointer
>>>
>>> Regarding the options given for "whose `count` to use"--which option is
>>> actually being proposed?
>>>
>>
>> I don’t understand the question,, `UnsafeMutableRawPointer` takes an
>> explicit `count:`. the “whose count to use” option is irrelevant.
>>
>
> In "Proposed Solution," under subheading "UnsafeMutableRawPointer," you
> write "the question of whose `count` to use becomes important." You then
> outline "[o]ne option" as well as "[a] better option." Which of these
> options are you actually proposing? For clarity, could you please excise
> the non-proposed option from the "Proposed Solution" section and move it to
> the "Alternatives Considered" section?
>

The *Proposed solution* section is divided into two parts, one dealing with
plain pointers and one dealing with buffer pointers. The sections are
separated by the horizontal rule above “*Buffer pointers are conceptually
similar…*”. I don’t know why we’re arguing over typographic formatting but
I am glad this proposal is noncontroversial enough to induce debate over
its horizontal rules. As for the two options, the first is a strawman to
explain why we are going with the second option.


>
> ## UnsafeMutableBufferPointer
>>>
>>> Please clarify: why are you proposing that the `at:` arguments in
>>> `UnsafeMutableBufferPointer` and `UnsafeMutableRawBufferPointer`
>>> _should not_ receive default values, but the `at:` arguments in
>>> `UnsafeMutableRawPointer` _should_ receive a default value of `0`?
>>>
>>>
>>  The extant API for `UnsafeMutableRawPointer` already included these
>> default arguments which seem to be widely used in the stdlib,, the proposal
>> tries to avoid these kinds of source breakages wherever possible. We avoid
>> providing the default arguments on buffer pointers because we want the fact
>> that it takes a *start–length* segment pair to be obvious at the call
>> site.
>>
>
> Thanks for the clarification; that would be helpful information to put
> into the proposal text. It is not an intuitive start-length pair, since the
> `at` refers to an offset of the destination buffer but `count` refers to a
> length of the source buffer. I appreciate how you separated the proposed
> new argument `at` and the existing argument `count` in what is currently
> named `initializeMemory(as:from:count:)`, which helps to reinforce
> that fact.
>
>
>> Concerns:
>>>
>>> ## UnsafeMutablePointer
>>>
>>> It's alarming that omitting `count` in `initialize(repeating:count:)`
>>> (and assign, etc.) means initialize _one_ element, but elsewhere (such as
>>> `UnsafeMutableBufferPointer` means initialize _all_ elements. The behavior
>>> of the proposed API also contradicts its own spelling on its face:
>>> `initialize(repeating: foo)` means *do not repeat* `foo`.
>>>
>>> Yes, I understand the argument that `*BufferPointer` types have an
>>> intrinsic count, etc., but in the context of code where types are inferred,
>>> `let foo = T.allocate(capacity: 100); foo.initialize(repeating: bar)`
>>> should not mean one thing for `*BufferPointer` types and a totally
>>> different thing for

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

[Taylor Swift via swift-evolution]

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]Pointer: add missing
>> methods, adjust existing labels for clarity, and remove deallocation size"
>> begins now and runs through September 7, 2017. The proposal is available
>> here:
>>
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/0184-unsafe-pointers-add-missing.md
>>
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> or, if you would like to keep your feedback private, directly to the
>> review manager. When replying, please try to keep the proposal link at the
>> top of the message:
>>
>> Proposal link:
>>
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/0184-unsafe-pointers-add-missing.md
>>
>> Reply text
>>
>> Other replies
>>
>> What
>> goes into a review?
>>
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and, eventually, determine the direction of
>> Swift. When writing your review, here are some questions you might want to
>> answer in your review:
>>
>>- What is your evaluation of the proposal?
>>
>> Overall, this is an improvement. However, I do have some questions and
> concerns:
>
>
> Questions:
>
> ## UnsafeMutableRawPointer
>
> Regarding the options given for "whose `count` to use"--which option is
> actually being proposed?
>

I don’t understand the question,, `UnsafeMutableRawPointer` takes an
explicit `count:`. the “whose count to use” option is irrelevant.


>
> ## UnsafeMutableBufferPointer
>
> Please clarify: why are you proposing that the `at:` arguments in
> `UnsafeMutableBufferPointer` and `UnsafeMutableRawBufferPointer` _should
> not_ receive default values, but the `at:` arguments in
> `UnsafeMutableRawPointer` _should_ receive a default value of `0`?
>
>
 The extant API for `UnsafeMutableRawPointer` already included these
default arguments which seem to be widely used in the stdlib,, the proposal
tries to avoid these kinds of source breakages wherever possible. We avoid
providing the default arguments on buffer pointers because we want the fact
that it takes a *start–length* segment pair to be obvious at the call site.

Concerns:
>
> ## UnsafeMutablePointer
>
> It's alarming that omitting `count` in `initialize(repeating:count:)` (and
> assign, etc.) means initialize _one_ element, but elsewhere (such as
> `UnsafeMutableBufferPointer` means initialize _all_ elements. The behavior
> of the proposed API also contradicts its own spelling on its face:
> `initialize(repeating: foo)` means *do not repeat* `foo`.
>
> Yes, I understand the argument that `*BufferPointer` types have an
> intrinsic count, etc., but in the context of code where types are inferred,
> `let foo = T.allocate(capacity: 100); foo.initialize(repeating: bar)`
> should not mean one thing for `*BufferPointer` types and a totally
> different thing for plain `*Pointer` types--particularly when both can be
> allocated with a certain capacity greater than one.
>
> Either `count` should always be required, or for convenience there should
> be a separate overload `initialize(pointee:)` that does not require `count`.
>
>
I understand the naming is not optimal, but reams of discussion on this
list have concluded that it’s the least bad alternative available. We can’t
just get rid of the default value for `count:` because usage in real code
bases shows that this default argument is actually extremely useful. I
believe well over 90% of the calls to these methods in the standard library
currently rely on the default argument value. Renaming the `repeating:`
argument to `to:` would make the API inconsistent and hide the fact that
plain pointers are still capable of operating on many elements in sequence
— “`to:count:`” makes no grammatical sense to read — “to” is a singular
preposition.


>
> ## UnsafeMutableRawBufferPointer
>
> In `copyBytes`, the use of `Bytes` to emphasize that it's the memory
> that's being copied is thoughtful, but it is inconsistent with the other
> method names that use the terminology `Memory` for the same purpose (e.g.,
> `moveInitializeMemory` to clarify the meaning of `moveInitialize`).
>
> For better consistency--and since you're proposing to rename
> `copyBytes(from:count:)` on `UnsafeMutableRawPointer` to
> `copy(from:bytes:)`--this particular API on `UnsafeMutableRawBufferPointer`
> should be named `copyMemory(from:)` and not `copyBytes(from:)`.
>
> Although, actually, looking at the APIs on `UnsafeMutableRawPointer`
> itself, that particular method too might best be written as
> 

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

[Taylor Swift via swift-evolution]

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
Swift to Linux platforms.

On Thu, Aug 31, 2017 at 12:44 PM, John Pratt  wrote:

> XCode is not just one of many editors to edit Swift you asshole.
>
> It is 99% of all editors used.
>
>
>
> On Aug 31, 2017, at 11:27 AM, Taylor Swift  wrote:
>
> 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 large number of great open source editors.
>
> On Thu, Aug 31, 2017 at 7:53 AM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> A few thoughts:
>>
>> 1) I would like to see Xcode gain a couple more literal types using the
>> same strategy it does for Image and Color literals
>>
>> 2) I would LOVE to see simple equation typesetting in Xcode
>>
>> (Those two are mostly up to the Xcode team as opposed to swift, I suppose)
>>
>> 3) Why are we pretending like we can always edit swift in a ASCII
>> editor?  The argument that actually using unicode would break things
>> doesn’t seem valid, because Swift has supported unicode since version 1,
>> and people have been using it since that time to name both variables and
>> operators. That doesn’t mean we need a super fancy editor, but I think
>> requiring unicode awareness is completely reasonable.  If your editor from
>> the 1970’s breaks something, it is both your and your editor’s fault, not
>> the code or the library, because Swift has unicode in it’s spec.
>>
>> 4) I don’t think we should let the difficulty of typing certain things
>> stop us.  It is an issue we need to consider, but it is an issue which can
>> be solved fairly easily with good UI design if there is a need. Sure,
>> different editors might solve it in different ways, but they will all solve
>> it if it is useful (and in a few years, we will have all settled on the
>> best approach).  As people have mentioned, it can be difficult to type ‘{‘
>> on certain language layouts, so if we limited ourselves by that we couldn’t
>> do anything.  We shouldn’t adopt a lowest common denominator approach.
>>
>> 5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It
>> *won’t* be confusing if we let people do either ‘<=‘ or ‘≤’ (there is
>> research by Apple in the late 80’s that proves this).  We all learned the
>> symbol in math class. Even non-programmers know what it means.  Assigning
>> it any other meaning would be confusing because it’s meaning is so widely
>> known.  Every time I bring this up, I am told to just roll my own (which I
>> have)… but it means that my code will now clash with everyone else’s
>> identical implementation (because there is only one sane way to implement
>> it).  The fact that there are multiple identical implementations
>> interfering with each other (and no real way to make a significantly
>> different implementation) tells me it really should be part of swift
>> itself. Every time I bring it up, people complain about it being extended
>> ASCII instead of pure ASCII, and that it is hard to type on a German
>> keyboard (those people can either just type ‘<=‘ or use a better editor
>> which autocompletes ‘<=‘ to ‘≤’).
>>
>> 6) My recommendations for typing symbols would be:
>> a) Choose a subset of useful and well-known symbols instead of every
>> symbol
>> b) Allow autocomplete on those symbols by name
>> c) Optionally choose a little-used guardian character to start the names
>> of symbols (to avoid accidental autocompletion).
>>
>> Thanks,
>> Jon
>>
>>
>> On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I sent a postal envelope to the Swift team with an article I wrote,
>> arguing that
>> symbols and graphics would push the programming language forward.
>>
>> Wouldn’t it be nice to have an actual multiplication matrix broken out
>> into code,
>> instead of typing, “matrix()”?  It seems to me Swift has the chance to do
>> that.
>>
>> Also: why does "<==" still reside in code as "less than or equal to” when
>> there is a unicode equivalent that looks neat?
>>
>> Why can’t the square of x have a superscript of 2 instead of having
>> “pow(x,2)?
>> I think this would make programming much easier to deal with.
>>
>> I expound on this issue in my article:
>>
>> http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf
>>
>> Thank you for reading.
>>
>>
>> -John
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> 

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

[Taylor Swift via swift-evolution]

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 large number of great open source editors.

On Thu, Aug 31, 2017 at 7:53 AM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> A few thoughts:
>
> 1) I would like to see Xcode gain a couple more literal types using the
> same strategy it does for Image and Color literals
>
> 2) I would LOVE to see simple equation typesetting in Xcode
>
> (Those two are mostly up to the Xcode team as opposed to swift, I suppose)
>
> 3) Why are we pretending like we can always edit swift in a ASCII editor?
> The argument that actually using unicode would break things doesn’t seem
> valid, because Swift has supported unicode since version 1, and people have
> been using it since that time to name both variables and operators. That
> doesn’t mean we need a super fancy editor, but I think requiring unicode
> awareness is completely reasonable.  If your editor from the 1970’s breaks
> something, it is both your and your editor’s fault, not the code or the
> library, because Swift has unicode in it’s spec.
>
> 4) I don’t think we should let the difficulty of typing certain things
> stop us.  It is an issue we need to consider, but it is an issue which can
> be solved fairly easily with good UI design if there is a need. Sure,
> different editors might solve it in different ways, but they will all solve
> it if it is useful (and in a few years, we will have all settled on the
> best approach).  As people have mentioned, it can be difficult to type ‘{‘
> on certain language layouts, so if we limited ourselves by that we couldn’t
> do anything.  We shouldn’t adopt a lowest common denominator approach.
>
> 5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It *won’t*
> be confusing if we let people do either ‘<=‘ or ‘≤’ (there is research by
> Apple in the late 80’s that proves this).  We all learned the symbol in
> math class. Even non-programmers know what it means.  Assigning it any
> other meaning would be confusing because it’s meaning is so widely known.
> Every time I bring this up, I am told to just roll my own (which I have)…
> but it means that my code will now clash with everyone else’s identical
> implementation (because there is only one sane way to implement it).  The
> fact that there are multiple identical implementations interfering with
> each other (and no real way to make a significantly different
> implementation) tells me it really should be part of swift itself. Every
> time I bring it up, people complain about it being extended ASCII instead
> of pure ASCII, and that it is hard to type on a German keyboard (those
> people can either just type ‘<=‘ or use a better editor which autocompletes
> ‘<=‘ to ‘≤’).
>
> 6) My recommendations for typing symbols would be:
> a) Choose a subset of useful and well-known symbols instead of every symbol
> b) Allow autocomplete on those symbols by name
> c) Optionally choose a little-used guardian character to start the names
> of symbols (to avoid accidental autocompletion).
>
> Thanks,
> Jon
>
>
> On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I sent a postal envelope to the Swift team with an article I wrote,
> arguing that
> symbols and graphics would push the programming language forward.
>
> Wouldn’t it be nice to have an actual multiplication matrix broken out
> into code,
> instead of typing, “matrix()”?  It seems to me Swift has the chance to do
> that.
>
> Also: why does "<==" still reside in code as "less than or equal to” when
> there is a unicode equivalent that looks neat?
>
> Why can’t the square of x have a superscript of 2 instead of having
> “pow(x,2)?
> I think this would make programming much easier to deal with.
>
> I expound on this issue in my article:
>
> http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf
>
> Thank you for reading.
>
>
> -John
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 review have been addressed.
>
> -Andy
>
> On Aug 22, 2017, at 12:59 PM, Michael Ilseman  wrote:
>
> This is an excellent, thoroughly thought out, and well written proposal!
> I’m eager to see these improvements land.
>
>
> On Aug 22, 2017, at 11:33 AM, Taylor Swift  wrote:
>
>
>
> 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.de
>>> initialize()`. It is incorrect
>>> for the typical use case and doesn't appear to solve any important use
>>> case. The *only* fully initializing method is `initialize(repeating:)`, but
>>> that will usually be used for trivial values, which should not be
>>> deinitialized. It's preferable for the user to explicitly deinitialize just
>>> the segments that they know were initialized, which can be done on the base
>>> pointer. The only benefit in having a `deinitialize` on the buffer is to
>>> communicate to users who see the `initialize` API for the first time that
>>> it is their responsibility to deinitialize if the type requires it. To that
>>> end, we could add a `deinitialize(at:count:)` method, communicating the
>>> symmetry with `initialize(at:from:). Naturally `index + count <=
>>> self.count`.
>>>
>>> -Andy
>>>
>>
>> I don’t agree with this. If `deinitialize()` is a problem because it
>> deinitializes the entire buffer, so are `moveAssign` and `moveInitialize`.
>> They all assume the released buffer operand is fully initialized. `
>> deinitialize()` has just as much use as the other full-buffer releasing
>> methods. Just take the image buffer example there
>>
>>
>> `moveAssign` and `moveInitialize` assume that the sub-buffer being moved
>> from is fully initialized. That’s already obvious because the user is
>> asking to move source.count elements. I don’t see any use cases where it
>> would pose a problem. If the user is moving out of a partially initialized
>> buffer, they have already to sliced (and unfortunately rebased) the buffer.
>> OTOH `deinitialize` is incorrect for normal use cases. I don’t see any
>> practical analogy between those APIs.
>>
>> let pixels:Int = scanlines.map{ $0.count }.reduce(0, +)var image = 
>> UnsafeMutableBufferPointer.allocate(capacity: pixels)
>> var filled:Int = 0for scanline:UnsafeMutableBufferPointer in scanlines
>> {
>> image.moveInitialize(at: filled, from: scanline)
>> filled += scanline.count
>> }
>>
>> image.deinitialize()
>>
>> We don’t want developers to do this. Instead we want to see an explicitly
>> named association between the number of items initialized and deinitialized:
>>
>> image.deinitialize(at: 0, count: filled)
>>
>> Flipping this around, it could be even more common to be writing into a
>> larger than necessary buffer (pixels > filled). If we’re providing
>> auto-slicing initializers, then deinitialization should follow the same
>> approach, rather than:
>>
>> UnsafeMutableBufferPointer(rebasing: image[0, filled]).deinitialize()
>>
>> image.deallocate()
>>
>> and replace `Pixel` with a class type like `UIButton`.
>>
>> And `deinitialize(at:count:)` is bad because you’re asking for a count
>> on a buffer method. `moveAssign` and `moveInitialize` can take range
>> parameters because they each have a second operand that supplies the count
>> number. `deinitialize` doesn’t. That means calls could end up looking
>> like
>>
>> buffer.deinitialize(at: 0, count: buffer.count)
>>
>> which is exactly what we were trying to avoid in the first place.
>>
>>
>> But there is no value in avoiding the `count` argument here. That’s not a
>> valid motivation for introducing `deinitialize` on a buffer, and we’d be
>> better off not introducing it at all.
>>
>> The only valid motivation I can come up with for introducing
>> `deinitialize` on buffer is to remind developers who are only looking at
>> the buffer API (and not the plain pointer API) that it’s their
>> responsibility to manually deinitialize (it doesn’t automatically happen on
>> deallocation or destruction).
>>
>> -Andy
>>
>>
> I replaced UnsafeMutableBufferPointer.deinitialize() with
> UnsafeMutableBufferPointer.deinitialize(at:count:)
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

So are you saying we need *three* distinct “URI” types for local-absolute,
local-relative, and remote? That’s a lot of API surface to support.

On Tue, Aug 22, 2017 at 12:24 PM, Dave DeLong  wrote:

> I completely agree. URL packs a lot of punch, but IMO it’s the wrong
> abstraction for file system paths.
>
> I maintain an app that deals a *lot* with file system paths, and using
> URL has always felt cumbersome, but String is the absolute wrong type to
> use. Lately as I’ve been working on it, I’ve been experimenting with a
> concrete “Path” type, similar to PathKit (https://github.com/kylef/
> PathKit/). Working in terms of AbsolutePath and RelativePath (what I’ve
> been calling things) has been *extremely* refreshing, because it allows
> me to better articulate the kind of data I’m dealing with. URL doesn’t
> handle pure-relative paths very well, and it’s always a bit of a mystery
> how resilient I need to be about checking .isFileURL or whatever. All the
> extra properties (port, user, password, host) feel hugely unnecessary as
> well.
>
> Dave
>
> On Aug 20, 2017, at 11:23 PM, Félix Cloutier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'm not convinced that URLs are the appropriate abstraction for a file
> system path. For the record, I'm not a fan of existing Foundation methods
> that create objects from an URL. There is a useful and fundamental
> difference between a local path and a remote path, and conflating the two
> has been a security pain point in many languages and frameworks that allow
> it. Examples include remote file inclusion in PHP and malicious doctypes in
> XML. Windows also had its share of issues with UNC paths.
>
> Even when loading an arbitrary URL looks innocuous, many de-anonymizing
> hacks work by causing a program to access an URL controlled by an attacker
> to make it disclose the user's IP address or some other identifier.
>
> IMO, this justifies that there should be separate 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 Swift via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Okay so a few days ago there was a discussion
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038923.html>
> 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 is currently little more than a wrapper for NSURL),
> so I’ve just started a pure Swift URL library project at <
> https://github.com/kelvin13/url>.
>
> The library’s parsing and validation core (~1K loc pure swift) is already
> in place and functional; the goal is to eventually support all of the
> Foundation URL functionality.
>
> The new `URL` type is implemented as a value type with utf8 storage backed
> by an array buffer. The URLs are just 56 bytes long each, so they should be
> able to fit into cache lines. (NSURL by comparison is over 128 bytes in
> size; it’s only saved by the fact that the thing is passed as a reference
> type.)
>
> As I said, this is still really early on and not a mature library at all
> but everyone is invited to observe, provide feedback, or contribute!
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 to solve any important use case. The
>> *only* fully initializing method is `initialize(repeating:)`, but that will
>> usually be used for trivial values, which should not be deinitialized. It's
>> preferable for the user to explicitly deinitialize just the segments that
>> they know were initialized, which can be done on the base pointer. The only
>> benefit in having a `deinitialize` on the buffer is to communicate to users
>> who see the `initialize` API for the first time that it is their
>> responsibility to deinitialize if the type requires it. To that end, we
>> could add a `deinitialize(at:count:)` method, communicating the symmetry
>> with `initialize(at:from:). Naturally `index + count <= self.count`.
>>
>> -Andy
>>
>
> I don’t agree with this. If `deinitialize()` is a problem because it
> deinitializes the entire buffer, so are `moveAssign` and `moveInitialize`.
> They all assume the released buffer operand is fully initialized. `
> deinitialize()` has just as much use as the other full-buffer releasing
> methods. Just take the image buffer example there
>
>
> `moveAssign` and `moveInitialize` assume that the sub-buffer being moved
> from is fully initialized. That’s already obvious because the user is
> asking to move source.count elements. I don’t see any use cases where it
> would pose a problem. If the user is moving out of a partially initialized
> buffer, they have already to sliced (and unfortunately rebased) the buffer.
> OTOH `deinitialize` is incorrect for normal use cases. I don’t see any
> practical analogy between those APIs.
>
> let pixels:Int = scanlines.map{ $0.count }.reduce(0, +)var image = 
> UnsafeMutableBufferPointer.allocate(capacity: pixels)
> var filled:Int = 0for scanline:UnsafeMutableBufferPointer in scanlines
> {
> image.moveInitialize(at: filled, from: scanline)
> filled += scanline.count
> }
>
> image.deinitialize()
>
> We don’t want developers to do this. Instead we want to see an explicitly
> named association between the number of items initialized and deinitialized:
>
> image.deinitialize(at: 0, count: filled)
>
> Flipping this around, it could be even more common to be writing into a
> larger than necessary buffer (pixels > filled). If we’re providing
> auto-slicing initializers, then deinitialization should follow the same
> approach, rather than:
>
> UnsafeMutableBufferPointer(rebasing: image[0, filled]).deinitialize()
>
> image.deallocate()
>
> and replace `Pixel` with a class type like `UIButton`.
>
> And `deinitialize(at:count:)` is bad because you’re asking for a count on
> a buffer method. `moveAssign` and `moveInitialize` can take range
> parameters because they each have a second operand that supplies the count
> number. `deinitialize` doesn’t. That means calls could end up looking like
>
>
> buffer.deinitialize(at: 0, count: buffer.count)
>
> which is exactly what we were trying to avoid in the first place.
>
>
> But there is no value in avoiding the `count` argument here. That’s not a
> valid motivation for introducing `deinitialize` on a buffer, and we’d be
> better off not introducing it at all.
>
> The only valid motivation I can come up with for introducing
> `deinitialize` on buffer is to remind developers who are only looking at
> the buffer API (and not the plain pointer API) that it’s their
> responsibility to manually deinitialize (it doesn’t automatically happen on
> deallocation or destruction).
>
> -Andy
>
>
I replaced UnsafeMutableBufferPointer.deinitialize() with
UnsafeMutableBufferPointer.deinitialize(at:count:)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 is up here: <https://github.com/kelvin13/s
>> wift-evolution/blob/patch-3/proposals/0184-improved-pointers.md>
>>
>> Important changes start here
>> <https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md#proposed-solution>
>> .
>>
>>
>> I have more feedback for you after discussing with Ben and Michael.
>>
>> Under the section "Background". The retaining/releasing counts are
>> confusing because we normally talk about "+0/+1" with respect to a single
>> value. Here you're summing the reference count effect across different
>> source and destination values. I think you can drop the -1/+0/+1 from the
>> cell labels and just label the headers as "Source-Copy(+1) vs.
>> Source-Move(+0)" and "Dest-Initializing(+0)" vs. "Dest-Destroying(-1)".
>>
>
> I got rid of the total counts, but I used “retaining” and “releasing”
> because the word “initialize” is already way overloaded in the document and
> using it as a category in addition to referring to the actual method family
> `initialize` and `initializeMemory` and Swift’s `init` initializers would
> just get too confusing.
>
>
>>
>> Ben noticed that we still don't have 
>> `UnsafeMutableBufferPointer.deallocate()`.
>> Please add that as well.
>>
>
> This is in the implementation and 2/3 of the API mocks; idk why it was
> lost in the detailed changes section. That was a typo I just fixed it
>
>
>> I think you should also add the default `alignedTo:Int =
>> MemoryLayout.alignment` to `UnsafeRawMutablePointer`. It is
>> effectively part of Swift's memory model... [Background: We're providing a
>> language level default guarantee of word-aligned storage. We don't want to
>> expose the platform's default alignment. There is no such thing as a
>> "maximal" alignment for all imported primitive types. We expect allocators
>> to typically provide 16-byte alignment, but when developers are relying on
>> that for correctness, we want it to be explicit. Developers usually rely on
>> word alignment so there's no value in making that explicit.]
>>
>
> done and committed
>
>
>>
>> The source breaking changes can be marked deprecated for now, but can
>> only be marked unavailable in Swift 5 mode or later.
>>
>
> done and committed
>
>
>>
>> We anticipate adding a ContiguouslyStored protocol "soon", which could be
>> used to reduce the amount of overloading on the buffer
>> `initialize`/`assign` APIs. But we need a lot more time to iterate on that
>> design and it doesn't appear that migrating to it would be source breaking
>> w.r.t. your proposal.
>>
>> I think we would be receptive to a "non-Optional baseAddress" proposal
>> now if you or anyone else wants to pitch that. I know Dave Abrahams had a
>> working implementation at some point. That would weaken some of the
>> incentive to continue adding more convenience to buffer slices.
>>
>
> Really early versions of this proposal pitched that but it didn’t go so
> well. also making baseAddress nonnillable means you don’t always have
> access to `count` when `count == 0`
>
>
>>
>> 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 to solve any important use case. The
>> *only* fully initializing method is `initialize(repeating:)`, but that will
>> usually be used for trivial values, which should not be deinitialized. It's
>> preferable for the user to explicitly deinitialize just the segments that
>> they know were initialized, which can be done on the base pointer. The only
>> benefit in having a `deinitialize` on the buffer is to communicate to users
>> who see the `initialize` API for the first time that it is their
>> responsibility to deinitialize if the type requires it. To that end, we
>> could add a `deinitialize(at:count:)` method, communicating the symmetry
>> with `initialize(at:from:). Naturally `index + count <= self.count`.
>>
>> -Andy
>>
>
> I don’t agree with this. If `deinitialize()` is a problem because it
> deinitializes the entire buffer, so a

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

[Taylor Swift via swift-evolution]

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
> 
> .
>
>
> I have more feedback for you after discussing with Ben and Michael.
>
> Under the section "Background". The retaining/releasing counts are
> confusing because we normally talk about "+0/+1" with respect to a single
> value. Here you're summing the reference count effect across different
> source and destination values. I think you can drop the -1/+0/+1 from the
> cell labels and just label the headers as "Source-Copy(+1) vs.
> Source-Move(+0)" and "Dest-Initializing(+0)" vs. "Dest-Destroying(-1)".
>

I got rid of the total counts, but I used “retaining” and “releasing”
because the word “initialize” is already way overloaded in the document and
using it as a category in addition to referring to the actual method family
`initialize` and `initializeMemory` and Swift’s `init` initializers would
just get too confusing.


>
> Ben noticed that we still don't have 
> `UnsafeMutableBufferPointer.deallocate()`.
> Please add that as well.
>

This is in the implementation and 2/3 of the API mocks; idk why it was lost
in the detailed changes section. That was a typo I just fixed it


> I think you should also add the default `alignedTo:Int =
> MemoryLayout.alignment` to `UnsafeRawMutablePointer`. It is
> effectively part of Swift's memory model... [Background: We're providing a
> language level default guarantee of word-aligned storage. We don't want to
> expose the platform's default alignment. There is no such thing as a
> "maximal" alignment for all imported primitive types. We expect allocators
> to typically provide 16-byte alignment, but when developers are relying on
> that for correctness, we want it to be explicit. Developers usually rely on
> word alignment so there's no value in making that explicit.]
>

done and committed


>
> The source breaking changes can be marked deprecated for now, but can only
> be marked unavailable in Swift 5 mode or later.
>

done and committed


>
> We anticipate adding a ContiguouslyStored protocol "soon", which could be
> used to reduce the amount of overloading on the buffer
> `initialize`/`assign` APIs. But we need a lot more time to iterate on that
> design and it doesn't appear that migrating to it would be source breaking
> w.r.t. your proposal.
>
> I think we would be receptive to a "non-Optional baseAddress" proposal now
> if you or anyone else wants to pitch that. I know Dave Abrahams had a
> working implementation at some point. That would weaken some of the
> incentive to continue adding more convenience to buffer slices.
>

Really early versions of this proposal pitched that but it didn’t go so
well. also making baseAddress nonnillable means you don’t always have
access to `count` when `count == 0`


>
> 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 to solve any important use case. The
> *only* fully initializing method is `initialize(repeating:)`, but that will
> usually be used for trivial values, which should not be deinitialized. It's
> preferable for the user to explicitly deinitialize just the segments that
> they know were initialized, which can be done on the base pointer. The only
> benefit in having a `deinitialize` on the buffer is to communicate to users
> who see the `initialize` API for the first time that it is their
> responsibility to deinitialize if the type requires it. To that end, we
> could add a `deinitialize(at:count:)` method, communicating the symmetry
> with `initialize(at:from:). Naturally `index + count <= self.count`.
>
> -Andy
>

I don’t agree with this. If `deinitialize()` is a problem because it
deinitializes the entire buffer, so are `moveAssign` and `moveInitialize`.
They all assume the released buffer operand is fully initialized. `
deinitialize()` has just as much use as the other full-buffer releasing
methods. Just take the image buffer example there

let pixels:Int = scanlines.map{ $0.count }.reduce(0, +)var image =
UnsafeMutableBufferPointer.allocate(capacity: pixels)
var filled:Int = 0for scanline:UnsafeMutableBufferPointer in scanlines
{
image.moveInitialize(at: filled, from: scanline)
filled += scanline.count
}

image.deinitialize()
image.deallocate()

and replace `Pixel` with a class type like `UIButton`.

And `deinitialize(at:count:)` is bad because you’re asking for a count on a
buffer method. `moveAssign` and `moveInitialize` can take range parameters
because they each have a second operand that supplies the count number. `
deinitialize` doesn’t. That means calls could end up 

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

[Taylor Swift via swift-evolution]

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:
>
>>
>> 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: > wift-evolution/blob/patch-3/proposals/0184-improved-pointers.md>
>>
>> Important changes start here
>> 
>> .
>>
>>
>> This should be brought to the attention of swift-evolution:
>>
>> The old `deallocate(capacity:)` method should be marked
>> as `unavailable` since it currently encourages dangerously incorrect code.
>> This avoids misleading future users, forces current users to address this
>> potentially catastrophic memory bug, and leaves the possibility open for us
>> to add a `deallocate(capacity:)` method in the future, or perhaps even
>> a `reallocate(toCapacity:)` method.
>>
>>
>> I can’t defend breaking existing source without having seen real code
>> that was actually written incorrectly. I don’t see the downside of using
>> the same deprecation strategy as the other changes. I expect code that was
>> already written to be correct and future code to not call the deprecated
>> API.
>>
>>
>> It would have to be deprecated in Swift 4 mode. For beyond-4 mode, are
>> you arguing it should remain deprecated or can it become obsoleted?
>>
>
> I mean I just thought that it would be best to get rid of this as quickly
> and harshly as possible because a lot of people might think their code was
> correct when in fact it wasn’t (the example in the document is biased to
> segfault but if the lengths are smaller, a segfault might not occur, even
> though invalid access is still being done.)
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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-evolution/blob/patch-3/proposals/0184-improved-pointers.md>
>
> Important changes start here
> 
> .
>
>
> This should be brought to the attention of swift-evolution:
>
> The old `deallocate(capacity:)` method should be marked
> as `unavailable` since it currently encourages dangerously incorrect code.
> This avoids misleading future users, forces current users to address this
> potentially catastrophic memory bug, and leaves the possibility open for us
> to add a `deallocate(capacity:)` method in the future, or perhaps even
> a `reallocate(toCapacity:)` method.
>
>
> I can’t defend breaking existing source without having seen real code that
> was actually written incorrectly. I don’t see the downside of using the
> same deprecation strategy as the other changes. I expect code that was
> already written to be correct and future code to not call the deprecated
> API.
>
>
> It would have to be deprecated in Swift 4 mode. For beyond-4 mode, are you
> arguing it should remain deprecated or can it become obsoleted?
>

I mean I just thought that it would be best to get rid of this as quickly
and harshly as possible because a lot of people might think their code was
correct when in fact it wasn’t (the example in the document is biased to
segfault but if the lengths are smaller, a segfault might not occur, even
though invalid access is still being done.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

that might be true but I’d need to hear from more people to justify
creating two very similar URI types. Technically `file:` is just a string
that the file system interpreter gives meaning to; the scheme of a URL can
be any alphanumeric string. For example you could write a file manager
which interprets "foo:" as a local address, or ignore the scheme entirely.

On Mon, Aug 21, 2017 at 11:23 AM, Félix Cloutier 
wrote:

> There's no question that there's a lot in common between file: URLs and
> other URLs, but that hardly makes URLs better in the file: case.
>
> I saw the enum. The problem remains that it's a common API principle to
> accept the broadest possible input. It's not fundamentally wrong to accept
> and resolve common URL types, as there's a ton of things that need to read
> documents from the Internet by design. However, if this is the default
> facility for file handling too, it invents either:
>
>
>- A responsibility for API users to check that their URL is a file:
>URL;
>- A responsibility for API authors to provide separate entry points
>for file URLs and remote URLs, and a responsibility for API users to use
>the right one.
>
>
> It would also add a category of errors to common filesystem operations:
> "can't do this because the URL is not a file: URL", and a category of
> questions that we arguably shouldn't need to ask ourselves. For instance,
> what is the correct result of glob()ing a file: URL pattern with a hash or
> a query string, should each element include that hash/query string too?
>
> Félix
>
> Le 20 août 2017 à 23:33, Taylor Swift  a écrit :
>
> I think that’s more a problem that lies in Foundation methods that take
> URLs rather than the URLs themselves. A URL is a useful abstraction because
> it contains a lot of common functionality between local file paths and
> internet resources. For example, relative URI reference resolution. APIs
> which take URLs as arguments should be responsible for ensuring that the
> URL’s schema is a `file:`. The new URL type I’m writing actually makes
> the scheme an enum with cases `.file`, `.http`, `.https`, `.ftp`, and `
> .data` to ease checking this.
>
> On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier 
> wrote:
>
>> I'm not convinced that URLs are the appropriate abstraction for a file
>> system path. For the record, I'm not a fan of existing Foundation methods
>> that create objects from an URL. There is a useful and fundamental
>> difference between a local path and a remote path, and conflating the two
>> has been a security pain point in many languages and frameworks that allow
>> it. Examples include remote file inclusion in PHP and malicious doctypes in
>> XML. Windows also had its share of issues with UNC paths.
>>
>> Even when loading an arbitrary URL looks innocuous, many de-anonymizing
>> hacks work by causing a program to access an URL controlled by an attacker
>> to make it disclose the user's IP address or some other identifier.
>>
>> IMO, this justifies that there should be separate 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 Swift via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>>
>> Okay so a few days ago there was a discussion
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038923.html>
>> 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 is currently little more than a wrapper for
>> NSURL), so I’ve just started a pure Swift URL library project at <
>> https://github.com/kelvin13/url>.
>>
>> The library’s parsing and validation core (~1K loc pure swift) is already
>> in place and functional; the goal is to eventually support all of the
>> Foundation URL functionality.
>>
>> The new `URL` type is implemented as a value type with utf8 storage
>> backed by an array buffer. The URLs are just 56 bytes long each, so they
>> should be able to fit into cache lines. (NSURL by comparison is over 128
>> bytes in size; it’s only saved by the fact that the thing is passed as a
>> reference type.)
>>
>> As I said, this is still really early on and not a mature library at all
>> but everyone is invited to observe, provide feedback, or contribute!
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

I think that’s more a problem that lies in Foundation methods that take
URLs rather than the URLs themselves. A URL is a useful abstraction because
it contains a lot of common functionality between local file paths and
internet resources. For example, relative URI reference resolution. APIs
which take URLs as arguments should be responsible for ensuring that the
URL’s schema is a `file:`. The new URL type I’m writing actually makes the
scheme an enum with cases `.file`, `.http`, `.https`, `.ftp`, and `.data`
to ease checking this.

On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier 
wrote:

> I'm not convinced that URLs are the appropriate abstraction for a file
> system path. For the record, I'm not a fan of existing Foundation methods
> that create objects from an URL. There is a useful and fundamental
> difference between a local path and a remote path, and conflating the two
> has been a security pain point in many languages and frameworks that allow
> it. Examples include remote file inclusion in PHP and malicious doctypes in
> XML. Windows also had its share of issues with UNC paths.
>
> Even when loading an arbitrary URL looks innocuous, many de-anonymizing
> hacks work by causing a program to access an URL controlled by an attacker
> to make it disclose the user's IP address or some other identifier.
>
> IMO, this justifies that there should be separate 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 Swift via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Okay so a few days ago there was a discussion
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038923.html>
> 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 is currently little more than a wrapper for NSURL),
> so I’ve just started a pure Swift URL library project at <
> https://github.com/kelvin13/url>.
>
> The library’s parsing and validation core (~1K loc pure swift) is already
> in place and functional; the goal is to eventually support all of the
> Foundation URL functionality.
>
> The new `URL` type is implemented as a value type with utf8 storage backed
> by an array buffer. The URLs are just 56 bytes long each, so they should be
> able to fit into cache lines. (NSURL by comparison is over 128 bytes in
> size; it’s only saved by the fact that the thing is passed as a reference
> type.)
>
> As I said, this is still really early on and not a mature library at all
> but everyone is invited to observe, provide feedback, or contribute!
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 is currently little more than a wrapper for NSURL),
so I’ve just started a pure Swift URL library project at <
https://github.com/kelvin13/url>.

The library’s parsing and validation core (~1K loc pure swift) is already
in place and functional; the goal is to eventually support all of the
Foundation URL functionality.

The new `URL` type is implemented as a value type with utf8 storage backed
by an array buffer. The URLs are just 56 bytes long each, so they should be
able to fit into cache lines. (NSURL by comparison is over 128 bytes in
size; it’s only saved by the fact that the thing is passed as a reference
type.)

As I said, this is still really early on and not a mature library at all
but everyone is invited to observe, provide feedback, or contribute!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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:)
>> moveAssign(from:at:)
>>
>> which provides maximum explicitness. This requires improvements to buffer
>> pointer slicing though. But I’m not a fan of the mission creep that’s
>> working into this proposal (i only originally wrote the thing to get
>> allocate(capacity:) and deallocate() into UnsafeMutableBufferPointer!)
>>
>>
>> I’m open to that, with source.count <= self.count + index. They are
>> potentially ambiguous (the `at` could refer to a source index) but
>> consistent with the idea that this API is for copying an entire source
>> buffer into a slice of the destination buffer. Again, we need to find real
>> code that benefits from this, but I expect the stdlib could use these.
>>
>
> In case that typo wasn’t obvious, we actually want the precondition:
> `offset + source.count <= self.count` (your latest proposal draft is
> correct).
>
> The more I think the more I believe using from:at: is the right approach.
> The only problem is that it would have to be written as a generic on
> Collectionor Sequence to avoid having to provide up to 4 overloads for
> each operation, since we would want these to work well with buffer slices
> as well as buffers themselves. That puts them uncomfortably close to the
> turf of the existing buffer pointer Sequence API though.
>
>
> It would have to be a generic method taking a RandomAccessCollection.
> Calling that would rely on tricky type inference. For now, I prefer the
> explicitly typed API in your current proposal.
>
> Or we could make UnsafeMutableBufferPointer its own slice type. Right now
> MutableRandomAccessSlice> takes up 4
> words of storage when it really only needs two.
>
>
> A slice needs to be a separate type because of the indexing semantics:
> https://github.com/apple/swift-evolution/commit/
> c8165b41b188c3d095425a0b4636fcf299ee9036
>
> Note that it's actually a feature that Subsequence refers back to its
> original buffer. If we cared enough, we could define a buffer slice type
> that exposes most of the buffer API. I just don't think we need to worry
> about that level of convenience yet, especially with you adding the `at:`
> labels. I'm fine if developers resort to `init(rebasing:)` in rare cases.
> Again, once we have a safe move-only or reference counted buffer type, that
> will be the better choice for Swift APIs. For now, this is still largely
> driven by C interop.
>

a method like `buffer.segment(0 ..< 5)` or something which would avoid
constructing the slice type (and save typing that long
`UnsafeMutableBufferPointer(rebasing:)` name) like that would be nice . but
that’s just sugar and not very important if you ask me


>
> I like this proposal as it stands!
> https://github.com/kelvin13/swift-evolution/blob/
> 9d305ced7b82b9cf5854b55b3f0d08952853d046/proposals/0184-
> improved-pointers.md
>
> -Andy
>

I’ll try to get an updated implementation out in the next few days
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

New draft of the proposal is up here: <
https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md
>

Important changes start here
<https://github.com/kelvin13/swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md#proposed-solution>
.

On 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@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:
>>
>>
>>
>> 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 basically ignored the Sequence methods at
>>> the expense of greater API surface area.
>>>
>>>
>>> The Sequence methods don’t provide the simpler, more convenient form of
>>> initialization/deinitialization that I thought you wanted. I see two
>>> reasonable options.
>>>
>>> 1. Don’t provide any new buffer initialization/deinitialization
>>> convenience. i.e. drop UsafeMutableBufferPointer moveInitialize,
>>> moveAssign, and deinitialize from your proposal.
>>>
>>> 2. Provide the full set of convenience methods: initialize, assign,
>>> moveInitialize, and moveAssign assuming self.count==source.count. And
>>> provide deinitialize() to be used only in conjunction with those new
>>> initializers.
>>>
>>> The question is really whether those new methods are going to
>>> significantly simplify your code. If not, #1 is the conservative choice.
>>> Don't provide convenience which could be misused. Put off solving that
>>> problem until we can design a new move-only buffer type that tracks
>>> partially initialized state.
>>>
>>> -Andy
>>>
>>>
>> I’m not sure the answer is to just omit methods from
>> UnsafeMutableBufferPointer since most of the original complaints
>> circulated around having to un-nil baseAddress to do anything with them.
>>
>>
>> I know un-nil’ing baseAddress is horrible, but I don’t think working
>> around that is an important goal yet. Eventually there will be a much
>> safer, more convenient mechanism for manual allocation that doesn’t involve
>> “pointers". I also considered adding API surface to
>> UnsafeMutableBufferPointer.Slice, but that’s beyond what we should do
>> now and may also become irrelevant when we have a more sophisticated buffer
>> type.
>>
>> What if only unary methods should be added to UnsafeMutableBufferPointer
>> without count:, meaning:
>>
>> initialize(repeating:)
>>
>>
>> I actually have no problem with this one... except that it could be
>> confused with UnsafeMutablePointer.initialize(repeating:), but I’ll
>> ignore that since we already discussed it.
>>
>> assign(repeating:)
>> deinitialize()
>>
>>
>> These are fine only if we have use cases that warrant them AND those use
>> cases are expected to fully initialize the buffer, either via
>> initialize(repeating:) or initialize(from: buffer) with
>> precondition(source.count==self.count). They don’t really make sense for
>> the use case that I’m familiar with. Without clear motivating code
>> patterns, they aren’t worth the risk. “API Completeness” doesn’t have
>> intrinsic value.
>>
>
> An example use for assign(repeating:) would be to zero out an image buffer.
>
>
>>
>> and the other methods should take both an *offset* parameter instead of
>> a count parameter:
>>
>> initialize(from:at:)
>> assign(from:at:)
>> moveInitialize(from:at:)
>> moveAssign(from:at:)
>>
>> which provides maximum explicitness. This requires improvements to buffer
>> pointer slicing though. But I’m not a fan of the mission creep that’s
>> working into this proposal (i only originally wrote the thing to get
>> allocate(capacity:) and deallocate() into UnsafeMutableBufferPointer!)
>>
>>
>> I’m open to that, with source.count <= self.count + index. They are
>> potentially ambiguous (the `at` could refer to a source index) but
>> consist

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

[Taylor Swift via swift-evolution]

How disruptive would it be to move the `at:` parameter in `
UnsafeMutableRawPointer.initializeMemory(as:at:count:to:)` to a method in `
UnsafeMutableRawBufferPointer`?

(raw_ptr + 16).initializeMemory(as: UInt64.self, from: source, count: 5)

instead of

raw_ptr.initializeMemory(as: UInt64.self, 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:
>>
>>
>>
>> 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 basically ignored the Sequence methods at
>>> the expense of greater API surface area.
>>>
>>>
>>> The Sequence methods don’t provide the simpler, more convenient form of
>>> initialization/deinitialization that I thought you wanted. I see two
>>> reasonable options.
>>>
>>> 1. Don’t provide any new buffer initialization/deinitialization
>>> convenience. i.e. drop UsafeMutableBufferPointer moveInitialize,
>>> moveAssign, and deinitialize from your proposal.
>>>
>>> 2. Provide the full set of convenience methods: initialize, assign,
>>> moveInitialize, and moveAssign assuming self.count==source.count. And
>>> provide deinitialize() to be used only in conjunction with those new
>>> initializers.
>>>
>>> The question is really whether those new methods are going to
>>> significantly simplify your code. If not, #1 is the conservative choice.
>>> Don't provide convenience which could be misused. Put off solving that
>>> problem until we can design a new move-only buffer type that tracks
>>> partially initialized state.
>>>
>>> -Andy
>>>
>>>
>> I’m not sure the answer is to just omit methods from
>> UnsafeMutableBufferPointer since most of the original complaints
>> circulated around having to un-nil baseAddress to do anything with them.
>>
>>
>> I know un-nil’ing baseAddress is horrible, but I don’t think working
>> around that is an important goal yet. Eventually there will be a much
>> safer, more convenient mechanism for manual allocation that doesn’t involve
>> “pointers". I also considered adding API surface to
>> UnsafeMutableBufferPointer.Slice, but that’s beyond what we should do
>> now and may also become irrelevant when we have a more sophisticated buffer
>> type.
>>
>> What if only unary methods should be added to UnsafeMutableBufferPointer
>> without count:, meaning:
>>
>> initialize(repeating:)
>>
>>
>> I actually have no problem with this one... except that it could be
>> confused with UnsafeMutablePointer.initialize(repeating:), but I’ll
>> ignore that since we already discussed it.
>>
>> assign(repeating:)
>> deinitialize()
>>
>>
>> These are fine only if we have use cases that warrant them AND those use
>> cases are expected to fully initialize the buffer, either via
>> initialize(repeating:) or initialize(from: buffer) with
>> precondition(source.count==self.count). They don’t really make sense for
>> the use case that I’m familiar with. Without clear motivating code
>> patterns, they aren’t worth the risk. “API Completeness” doesn’t have
>> intrinsic value.
>>
>
> An example use for assign(repeating:) would be to zero out an image buffer.
>
>
>>
>> and the other methods should take both an *offset* parameter instead of
>> a count parameter:
>>
>> initialize(from:at:)
>> assign(from:at:)
>> moveInitialize(from:at:)
>> moveAssign(from:at:)
>>
>> which provides maximum explicitness. This requires improvements to buffer
>> pointer slicing though. But I’m not a fan of the mission creep that’s
>> working into this proposal (i only originally wrote the thing to get
>> allocate(capacity:) and deallocate() into UnsafeMutableBufferPointer!)
>>
>>
>> I’m open to that, with source.count <= self.count + index. They are
>> potentially ambiguous (the `at` could refer to a source index) but
>> consistent with the idea that this API is for copying an entire source
>> buffer into a slice of the destination buffer. Again, we need to find r

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

[Taylor Swift via swift-evolution]

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 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.
>>
>>
>> The Sequence methods don’t provide the simpler, more convenient form of
>> initialization/deinitialization that I thought you wanted. I see two
>> reasonable options.
>>
>> 1. Don’t provide any new buffer initialization/deinitialization
>> convenience. i.e. drop UsafeMutableBufferPointer moveInitialize,
>> moveAssign, and deinitialize from your proposal.
>>
>> 2. Provide the full set of convenience methods: initialize, assign,
>> moveInitialize, and moveAssign assuming self.count==source.count. And
>> provide deinitialize() to be used only in conjunction with those new
>> initializers.
>>
>> The question is really whether those new methods are going to
>> significantly simplify your code. If not, #1 is the conservative choice.
>> Don't provide convenience which could be misused. Put off solving that
>> problem until we can design a new move-only buffer type that tracks
>> partially initialized state.
>>
>> -Andy
>>
>>
> I’m not sure the answer is to just omit methods from
> UnsafeMutableBufferPointer since most of the original complaints
> circulated around having to un-nil baseAddress to do anything with them.
>
>
> I know un-nil’ing baseAddress is horrible, but I don’t think working
> around that is an important goal yet. Eventually there will be a much
> safer, more convenient mechanism for manual allocation that doesn’t involve
> “pointers". I also considered adding API surface to
> UnsafeMutableBufferPointer.Slice, but that’s beyond what we should do now
> and may also become irrelevant when we have a more sophisticated buffer
> type.
>
> What if only unary methods should be added to UnsafeMutableBufferPointer
> without count:, meaning:
>
> initialize(repeating:)
>
>
> I actually have no problem with this one... except that it could be
> confused with UnsafeMutablePointer.initialize(repeating:), but I’ll
> ignore that since we already discussed it.
>
> assign(repeating:)
> deinitialize()
>
>
> These are fine only if we have use cases that warrant them AND those use
> cases are expected to fully initialize the buffer, either via
> initialize(repeating:) or initialize(from: buffer) with
> precondition(source.count==self.count). They don’t really make sense for
> the use case that I’m familiar with. Without clear motivating code
> patterns, they aren’t worth the risk. “API Completeness” doesn’t have
> intrinsic value.
>

An example use for assign(repeating:) would be to zero out an image buffer.


>
> and the other methods should take both an *offset* parameter instead of a
> count parameter:
>
> initialize(from:at:)
> assign(from:at:)
> moveInitialize(from:at:)
> moveAssign(from:at:)
>
> which provides maximum explicitness. This requires improvements to buffer
> pointer slicing though. But I’m not a fan of the mission creep that’s
> working into this proposal (i only originally wrote the thing to get
> allocate(capacity:) and deallocate() into UnsafeMutableBufferPointer!)
>
>
> I’m open to that, with source.count <= self.count + index. They are
> potentially ambiguous (the `at` could refer to a source index) but
> consistent with the idea that this API is for copying an entire source
> buffer into a slice of the destination buffer. Again, we need to find real
> code that benefits from this, but I expect the stdlib could use these.
>
> -Andy
>

The more I think the more I believe using from:at: is the right approach.
The only problem is that it would have to be written as a generic on
Collection or Sequence to avoid having to provide up to 4 overloads for
each operation, since we would want these to work well with buffer slices
as well as buffers themselves. That puts them uncomfortably close to the
turf of the existing buffer pointer Sequence API though.

Or we could make UnsafeMutableBufferPointer its own slice type. Right now
MutableRandomAccessSlice> takes up 4
words of storage when it really only needs two.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 basically ignored the Sequence methods at
> the expense of greater API surface area.
>
>
> The Sequence methods don’t provide the simpler, more convenient form of
> initialization/deinitialization that I thought you wanted. I see two
> reasonable options.
>
> 1. Don’t provide any new buffer initialization/deinitialization
> convenience. i.e. drop UsafeMutableBufferPointer moveInitialize,
> moveAssign, and deinitialize from your proposal.
>
> 2. Provide the full set of convenience methods: initialize, assign,
> moveInitialize, and moveAssign assuming self.count==source.count. And
> provide deinitialize() to be used only in conjunction with those new
> initializers.
>
> The question is really whether those new methods are going to
> significantly simplify your code. If not, #1 is the conservative choice.
> Don't provide convenience which could be misused. Put off solving that
> problem until we can design a new move-only buffer type that tracks
> partially initialized state.
>
> -Andy
>
>
I’m not sure the answer is to just omit methods from
UnsafeMutableBufferPointer since most of the original complaints circulated
around having to un-nil baseAddress to do anything with them.

What if only unary methods should be added to UnsafeMutableBufferPointer
without count:, meaning:

initialize(repeating:)
assign(repeating:)
deinitialize()

and the other methods should take both an *offset* parameter instead of a
count parameter:

initialize(from:at:)
assign(from:at:)
moveInitialize(from:at:)
moveAssign(from:at:)

which provides maximum explicitness. This requires improvements to buffer
pointer slicing though. But I’m not a fan of the mission creep that’s
working into this proposal (i only originally wrote the thing to get
allocate(capacity:) and deallocate() into UnsafeMutableBufferPointer!)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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, Andrew Trick  wrote:

>
> On Aug 19, 2017, at 6:03 PM, Taylor Swift  wrote:
>
>
>
> 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. That being said, since copy(from:bytes:) and copyBytes(from:)
>>> don’t do any initialization and have no direct counterparts in
>>> UnsafeMutableBufferPointer, it’s okay if they have different behavior than
>>> the other methods.
>>>
>>>
>>> You astutely pointed out that the UnsafeMutableBufferPointer.deinitialize()
>>> method is dangerous, and I asked you to add a warning to its comments.
>>> However, given the danger, I think we need to justify adding the method to
>>> begin with. Are there real use cases that greatly benefit from it?
>>>
>>
>> I agree that’s a problem, which is why i was iffy on supporting partial
>> initialization to begin with. The use case is for things like growing
>> collections where you have to periodically move to larger storage. However,
>> deinitialize is no more dangerous than moveInitialize,
>> assign(repeating:count:), or moveAssign; they all deinitialize at least one
>> entire buffer. If deinitialize is to be omitted, so must a majority of the
>> unsafe pointer API.
>>
>>
>> Here's an alternative. Impose the precondition(source.count ==
>> self.count) to the following UnsafeMutableBufferPointer convenience methods
>> that you propose adding:
>>
>> +++ func assign(from:UnsafeBufferPointer)
>> +++ func assign(from:UnsafeMutableBufferPointer)
>> +++ func moveAssign(from:UnsafeMutableBufferPointer)
>> +++ func moveInitialize(from:UnsafeMutableBufferPointer)
>> +++ func initialize(from:UnsafeBufferPointer)
>> +++ func initialize(from:UnsafeMutableBufferPointer)
>>
>> I don't that introduces any behavior that is inconsistent with other
>> methods. `copyBytes` is a totally different thing that only works on
>> trivial types. The currently dominant use case for UnsafeBufferPointer,
>> partially initialized backing store, does not need to use your new
>> convenience methods. It can continue dropping down to pointer+count style
>> initialization/deinitialization.
>>
>> -Andy
>>
>
> the latest draft does not have assign(from:UnsafeMutableBufferPointer<
> Element>) or  initialize(from:UnsafeMutableBufferPointer), it
> uses the generic Sequence methods that are already there that do not
> require that precondition.
>
>
> Sorry, I was pasting from your original proposal. Here are the relevant
> methods from the latest draft:
>
> https://github.com/kelvin13/swift-evolution/blob/
> 1b7738513c00388b8de3b09769eab773539be386/proposals/0184-
> improved-pointers.md
>
> +++ func moveInitialize(from:UnsafeMutableBufferPointer)
> +++ func moveAssign(from:UnsafeMutableBufferPointer)
>
> But with the precondition, the `assign` method could be reasonably added
> back, right?
> +++ func assign(from:UnsafeMutableBufferPointer)
>
> Likewise, I don’t have a problem with initialize(from:
> UnsafeBufferPointer) where self.count==source.count. The Sequence
> initializer is different. It’s designed for the Array use case and forces
> the caller to deal with partial initialization.
>
> UnsafeMutableRawBufferPointer.moveInitializeMemory on the other hand
> probably doesn't need that precondition since there's no way to
> deinitialize. It just needs clear comments.
>
> -Andy
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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. That being said, since copy(from:bytes:) and copyBytes(from:)
>> don’t do any initialization and have no direct counterparts in
>> UnsafeMutableBufferPointer, it’s okay if they have different behavior than
>> the other methods.
>>
>>
>> You astutely pointed out that the UnsafeMutableBufferPointer.deinitialize()
>> method is dangerous, and I asked you to add a warning to its comments.
>> However, given the danger, I think we need to justify adding the method to
>> begin with. Are there real use cases that greatly benefit from it?
>>
>
> I agree that’s a problem, which is why i was iffy on supporting partial
> initialization to begin with. The use case is for things like growing
> collections where you have to periodically move to larger storage. However,
> deinitialize is no more dangerous than moveInitialize,
> assign(repeating:count:), or moveAssign; they all deinitialize at least one
> entire buffer. If deinitialize is to be omitted, so must a majority of the
> unsafe pointer API.
>
>
> Here's an alternative. Impose the precondition(source.count == self.count)
> to the following UnsafeMutableBufferPointer convenience methods that you
> propose adding:
>
> +++ func assign(from:UnsafeBufferPointer)
> +++ func assign(from:UnsafeMutableBufferPointer)
> +++ func moveAssign(from:UnsafeMutableBufferPointer)
> +++ func moveInitialize(from:UnsafeMutableBufferPointer)
> +++ func initialize(from:UnsafeBufferPointer)
> +++ func initialize(from:UnsafeMutableBufferPointer)
>
> I don't that introduces any behavior that is inconsistent with other
> methods. `copyBytes` is a totally different thing that only works on
> trivial types. The currently dominant use case for UnsafeBufferPointer,
> partially initialized backing store, does not need to use your new
> convenience methods. It can continue dropping down to pointer+count style
> initialization/deinitialization.
>
> -Andy
>

the latest draft does not have assign(from:UnsafeMutableBufferPointer<
Element>) or  initialize(from:UnsafeMutableBufferPointer), it uses
the generic Sequence methods that are already there that do not require
that precondition.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

I agree it’s probably a bad idea to add the default arg to those two
functions. However, the default argument in initialize(repeating:count:) is
there for backwards compatibility since it already had it before and
there’s like a hundred places in the stdlib that use this default value.

On Sat, 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 
> wrote:
>
>> I’ve revised the proposal based on what I learned from trying to
>> implement these changes. I think it’s worth tacking the existing methods
>> that take Sequences at the same time as this actually makes the design a
>> bit simpler.
>> <https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c>
>>
>> *The previous version
>> <https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907> of this
>> document ignored the generic initialization methods on
>> UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer, leaving them
>> to be overhauled at a later date, in a separate proposal. Instead, this
>> version of the proposal leverages those existing methods to inform a more
>> compact API design which has less surface area, and is more future-proof
>> since it obviates the need to design and add another (redundant) set of
>> protocol-oriented pointer APIs later.*
>>
>> On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift 
>> wrote:
>>
>>> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers
>>> is ready for community review, and I encourage everyone to look it over and
>>> provide feedback. Thank you!
>>> <https://github.com/apple/swift-evolution/blob/master/propos
>>> als/0184-improved-pointers.md>
>>>
>>
> Thanks for continuing to improve this proposal. It’s in great shape now.
>
> Upon rereading it today I have to say I strongly object to the `count = 1`
> default in the following two cases:
>
> + UnsafeMutablePointer.withMemoryRebound(to: count: Int = 1)
> + UnsafeMutableRawPointer.bindMemory(to:T.Type, count:Int = 1)
>   -> UnsafeMutablePointer
>
> To aid understanding, it needs to be clear at the call-site that binding
> memory only applies to the specified number of elements. It's a common
> mistake for users to think they can obtain a pointer to a different type,
> then use that pointer as a base to access other elements. These APIs are
> dangerous expert interfaces. We certainly don't want to make their usage
> more concise at the expense of clarity.
>
> In general, I think there's very little value in the `count=1` default,
> and it creates potential confusion on the caller side between the
> `BufferPointer` API and the `Pointer` API. For example:
>
> + initialize(repeating:Pointee, count:Int = 1)
>
> Seeing `p.initialize(repeating: x)`, the user may think `p` refers to the
> buffer instead of a pointer into the buffer and misunderstand the behavior.
>
> + UnsafeMutablePointer.deinitialize(count: Int = 1)
>
> Again, `p.deinitialize()` looks to me like it might be deinitializing an
> entire buffer.
>
> If the `count` label is always explicit, then there's a clear distinction
> between the low-level `pointer` APIs and the `buffer` APIs.
>
> The pointer-to-single-element case never seemed interesting enough to me
> to worry about making convenient. If I'm wrong about that, is there some
> real-world code you can point to where the count=1 default significantly
> improves clarity?
>
> -Andy
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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:
>>
>>>
>>> On Aug 8, 2017, at 8:44 PM, Taylor Swift  wrote:
>>>
>>> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot
>>> find such a function anywhere in the API. There is copyBytes(from:)
>>> ,
>>> but the documentation is messed up and mentions a nonexistent count: 
>>> argument
>>> over and over again. The documentation also doesn’t mention what happens if
>>> there is a length mismatch, so users are effectively relying on an
>>> implementation detail. I don’t know how to best resolve this.
>>>
>>>
>>> We currently have `UnsafeMutableRawBufferPointer.copyBytes(from:)`. I
>>> don’t think your proposal changes that. The current docs refer to the
>>> `source` parameter, which is correct. Docs refer to the parameter name, not
>>> the label name. So `source.count` is the size of the input. I was pointing
>>> out that it has the semantics: `debugAssert(source.count <= self.count)`.
>>>
>>> Your proposal changes `UnsafeRawPointer.copyBytes(from:count:)` to
>>> `UnsafeRawPointer.copy(from:bytes:)`. Originally we wanted to those API
>>> names to match, but I’m fine with your change. What is more important is
>>> that the semantics are the same as `copyBytes(from:)`. Furthermore, any new
>>> methods that you add that copy into a raw buffer (e.g.
>>> initializeMemory(as:from:count:)) should have similar behavior.
>>>
>>>
>> I’m fine with switching to taking the count from the source, though I
>> think taking the count from the destination is slightly better because
>> 1) the use cases I mentioned in the other email, and 2) all the other
>> memorystate functions use self.count instead of source.count, if they
>> take a source argument. But being consistent with the raw pointer
>> version is more important.
>>
>>
>> If it’s copying from a buffer it should not take a count, if it’s copying
>> from a pointer it obviously needs to take a count. What I mean by the two
>> versions being named consistently is simply that they’re both named
>> `copyBytes`. That really isn’t important though. The overflow/underflow
>> semantics being consistent are important.
>>
>> (Incidentally, the reason “bytes” needs to be in the somewhere name is
>> because this method isn’t capable of copying nontrivial values)
>>
>> Should the methods that don’t deal with raw buffers also be modified to
>> use the source argument (i.e. UnsafeMutableBufferPointer.ini
>> tialize(from:))?
>>
>>
>> I’m not sure what you mean by this. It also allows the destination to be
>> larger than the source. Initializing from a sequence does not trap on
>> overflow because we can’t guarantee the size of the sequence ahead of time.
>> When I talk about consistent overflow/underflow semantics, I’m only talking
>> about initializing one unsafe buffer/pointer from another unsafe
>> buffer/pointer.
>>
>> Also, was there a reason why UnsafeMutableRawBufferPoin
>> ter.copyBytes(from:) uses the source’s count instead of its own? Right
>> now this behavior is “technically” undocumented behavior (as the public
>> docs haven’t been updated) so if there was ever a time to change it, now
>> would be it.
>>
>>
>> Mainly because partial initialization is more expected than dropping data
>> on the floor. Ultimately, this should be whatever typical developers would
>> expect the behavior to be. I would be very hesitant to change the behavior
>> now though.
>>
>> -Andy
>>
>
> 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. That being said, since copy(from:bytes:) and copyBytes(from:)
> don’t do any initialization and have no direct counterparts in
> UnsafeMutableBufferPointer, it’s okay if they have different behavior than
> the other methods.
>
>
> You astutely pointed out that the UnsafeMutableBufferPointer.deinitialize()
> method is dangerous, and I asked you to add a warning to its comments.
> However, given the danger, I think we need to justify adding the method to
> begin with. Are there real use cases that greatly benefit from it?
>

I agree that’s a problem, which is why i was iffy on supporting partial
initialization to begin with. The use case is for things like growing
collections where you have to periodically move to larger storage. However,
deinitialize is no more dangerous than moveInitialize,
assign(repeating:count:), or moveAssign; they all deinitialize at least one
entire buffer. If deinitialize is to be omitted, so must a majority of the
unsafe pointer API.

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

[Taylor Swift via swift-evolution]

Added
<https://github.com/kelvin13/swift/commit/b457366150715ab86925e767872568cc8ea6aaa1>
those methods to the implementation and updated the proposal document.

On Fri, Aug 18, 2017 at 11:42 PM, Andrew Trick  wrote:

>
> On Aug 18, 2017, at 5:36 PM, Taylor Swift  wrote:
>
> Should 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 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 
>> wrote:
>>
>>> I’ve revised the proposal based on what I learned from trying to
>>> implement these changes. I think it’s worth tacking the existing methods
>>> that take Sequences at the same time as this actually makes the design
>>> a bit simpler.
>>> <https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c>
>>>
>>> *The previous version
>>> <https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907> of this
>>> document ignored the generic initialization methods on
>>> UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer, leaving them
>>> to be overhauled at a later date, in a separate proposal. Instead, this
>>> version of the proposal leverages those existing methods to inform a more
>>> compact API design which has less surface area, and is more future-proof
>>> since it obviates the need to design and add another (redundant) set of
>>> protocol-oriented pointer APIs later.*
>>>
>>> On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift 
>>> wrote:
>>>
>>>> Since Swift 5 just got opened up for proposals, SE-184 Improved
>>>> Pointers is ready for community review, and I encourage everyone to look it
>>>> over and provide feedback. Thank you!
>>>> <https://github.com/apple/swift-evolution/blob/master/propos
>>>> als/0184-improved-pointers.md>
>>>>
>>>>
>>
>> Would you mind adding a deallocate method to (nonmutable)
>> UnsafePointer/UnsafeBufferPointer to take care of
>> [SR-3309](https://bugs.swift.org/browse/SR-3309)?
>>
>> There’s simply nothing in the memory model that requires mutable memory
>> for deallocation.
>>
>> It fits right in with this proposal and hardly seems worth a separate one.
>>
>> -Andy
>>
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 the “is this library functionality or standard library
>>> functionality” argument is worth having, but if stdout and stdin are
>>> first-class citizens in the Swift world, so should stderr.
>>>
>>> As for bringing Foundation into the discussion, you can’t really talk
>>> about Foundation without also talking about the mountains of problems that
>>> come with the monolith pattern. But that’s a completely different
>>> conversation to be had.
>>>
>>
>> I'm not sure what you're getting at here, but I don't believe you've
>> addressed my question, which is: it's been firmly decided that I/O belongs
>> in Foundation, and Foundation does in fact offer such facilities--what is
>> missing from those facilities, and how can we fill it out?
>>
>>
>> Lots of I/O functionality is missing from Foundation. Foundation's design
>> from time immemorial is that generally only relatively simple and
>> high-level operations are available in Foundation itself, and if you want
>> to do complicated or non-portable things then you are expected to drop down
>> to POSIX or other C interfaces. That design works less well in Swift than
>> it did in Objective-C because Swift's interface with C, especially
>> low-level C, is often ugly.
>>
>> Simple example: there is no way to access file information directly via
>> NSFileHandle. You need to call NSFileHandle.fileDescriptor and pass that to
>>  fstat() or fcntl(). The NSFileHandle API in general is sparse and wholly
>> inadequate for sophisticated I/O.
>>
>
> So that's a good starting point for the discussion.
>
> What, in your opinion, should be the way forward in addressing this
> situation? Is there a realistic chance of writing a single comprehensive,
> cross-platform API that makes possible currently "complicated or
> non-portable things" on both macOS/iOS/tvOS/watchOS and Linux, and
> potentially Windows? If so, does that fit within the general category of
> filling out the currently sparse Foundation APIs or would that be a matter
> for a separate library? In the alternative, is it the right solution to
> make dropping down to POSIX marginally easier by re-exporting C APIs under
> a unified name, without attempting a single cross-platform API?
>
>
>
For what it’s worth, CoreFoundation appears to support windows
environments, at least for things like path manipulation. However atm it’s
not very relevant as Swift doesn’t run on Windows rn.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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/apple/swift/pull/11464
>
> On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift 
> wrote:
>
>> I’ve revised the proposal based on what I learned from trying to
>> implement these changes. I think it’s worth tacking the existing methods
>> that take Sequences at the same time as this actually makes the design a
>> bit simpler.
>> <https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c>
>>
>> *The previous version
>> <https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907> of this
>> document ignored the generic initialization methods on
>> UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer, leaving them
>> to be overhauled at a later date, in a separate proposal. Instead, this
>> version of the proposal leverages those existing methods to inform a more
>> compact API design which has less surface area, and is more future-proof
>> since it obviates the need to design and add another (redundant) set of
>> protocol-oriented pointer APIs later.*
>>
>> On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift 
>> wrote:
>>
>>> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers
>>> is ready for community review, and I encourage everyone to look it over and
>>> provide feedback. Thank you!
>>> <https://github.com/apple/swift-evolution/blob/master/propos
>>> als/0184-improved-pointers.md>
>>>
>>>
>
> Would you mind adding a deallocate method to (nonmutable) 
> UnsafePointer/UnsafeBufferPointer
> to take care of
> [SR-3309](https://bugs.swift.org/browse/SR-3309)?
>
> There’s simply nothing in the memory model that requires mutable memory
> for deallocation.
>
> It fits right in with this proposal and hardly seems worth a separate one.
>
> -Andy
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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
saying we should get rid of the underscore pattern or `@discardableResult`,,
so…
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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 function like `print(_:separator:terminator:)` or `
>> readLine(strippingNewline:)` to live anywhere but the standard library,
>> then it stands to reason that the stderr version should also live in the
>> standard library.
>>
>
> FWIW, FileHandle.standardInput, FileHandle.standardError,
> FileHandle.standardOutput, and FileHandle.nullDevice all live in Foundation.
>

Yet, we have print and readLine, but no printError.


>
>
>> * Foundation is “supposed” to be the core library that does these things,
>> but this isn’t a good thing. Rationale:
>>
>> * Foundation is literally an Objective C framework that’s written
>> with Swift syntax. The classes extend *NSObject*. You use them by
>> *subclassing* them and overriding open methods. This is patently
>> unswifty. Even parts of Foundation that look swifty on the outside (like `
>> URL`) are still backed by NS reference types internally.
>>
>> * To fix this would require a complete rewrite from the ground up,
>> that’s more than a straight port from the Objective C framework. Many on
>> this list have also expressed desire to use this chance to redesign these
>> APIs. Since we’d basically have to rewrite all of it, any effort to
>> modernize Foundation is basically writing a new core library.
>>
>> * Even if a piece of Foundation was rewritten like a real Swift
>> library, because of the monolith pattern, you still wind up importing a lot
>> of legacy code that shouldn’t be floating around your project. Using the
>> file system tools shouldn’t change `String`.
>>
>> * Foundation’s file system capabilities are really just a class wrapper
>> around Glibc/Darwin functions. So in a way, Foundation is already a sort of
>> unified import for C, except it brings in a whole load of Objective C cruft
>> with it.
>>
>> * Logically, this means in terms of the XY problem, Foundation is on
>> the Y side. Foundation is what happens if you rely on Swift’s C interop to
>> get the job done instead of building a true Swift solution, which would
>> involve Swift quarterbacking all the nasty system calls, instead of
>> Glibc/Darwin doing it.
>>
>> In conclusion,
>>
>> * What we need is a modern Swift solution for accessing file systems.
>>
>> * What we have to do right now is leverage Swift’s C interop to use
>> Glibc/Darwin, while handing imports and platform inconsistencies manually.
>>
>> * Eventually, the ideal would be for Swift to handle that in Swift,
>> instead of delegating to a platform-dependent C library, or at least
>> standardize things so that a swifty Swift library imports the right C
>> library for you, and exports a platform-independent set of symbols to the
>> user, or a higher level API.
>>
>> * Foundation is in many ways the worst of both worlds. It handles the
>> Glibc/Darwin import for us, but at the cost of an aging framework that runs
>> against the grain of good Swift design idioms.
>>
>
> As has been stated on this list by the core team, replacing Foundation or
> duplicating its functionality is a non-goal of the Swift project. The major
> focus of several initial proposals, and a considerable amount of effort on
> this list, was precisely to modernize Foundation so as to offer APIs that
> conform to Swift guidelines. This work remains ongoing, as there are a
> number of Foundation value types that have yet to be designed or
> implemented. And there is a whole open source project devoted to Foundation
> becoming a viable cross-platform library.
>
> So given these parameters, let's return to what you are talking about:
> what is deficient about Swift's core file system APIs, and how would you
> suggest that we address these deficiencies, given that the core team has
> stated that it is not up for debate that any such changes would be part of
> Foundation?
>

This probably isn’t the answer you were looking for, but, as explained,
*all* of it is deficient, so long as you still have to subclass FileManager
and catch CocoaErrors. The problem with Foundation is it tries to offer
core library features and support bridging to Cocoa types at the same time.
Those two goals aren’t very compatible. That’s why there’s such a day and
night difference between stdlib and “pure swift” code, and Foundation code.

So, within the parameters, I would suggest

* rewriting the Foundation file system API types as value and protocol
types, retire the delegate-driven pattern, and *drop* ReferenceConvertible
conformance.

* value types should be trivial value types, with the possible
exception of file streams which need to be closed.

* separate it as much as possible from other Foundation types, so as to
help disentangle the library from NSNumber and Date.

* inseparab

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

[Taylor Swift via swift-evolution]

On Thu, Aug 17, 2017 at 9:06 PM, Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu  wrote:
>
> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun  wrote:
>
>> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for
>> example), then discarding them via `_ in`, which is different from `Void ->
>> T` or `f(x) = 0 * x`. The domain could just as easily be (Foo(), "b", 💩,
>>  UIColor.red, { x: Int in x^x }). There are too many semantic shifts away
>> from "I would like to collect the execution of this closure n times" for it
>> to sit comfortably.
>>
>
> What arguments might help to alleviate this discomfort? Clearly, functions
> exist that can map this delightfully heterogeneous domain to some sort of
> range that the user wants. Would you feel better if we wrote instead the
> following?
>
> ```
> repeatElement((), count: 5).map { UIView() }
> ```
>
>
> My favorite solution is the array initializer. Something along the lines
> of `Array(count n: Int, generator: () -> T)`. I'm not sure it _quite_
> reaches standard library but I think it is a solid way to say "produce a
> collection with a generator run n times". It's a common  task. I was asking
> around about this, and found that a lot of us who work with both macOS and
> iOS and want to stress test interfaces do this very often. Other use cases
> include "give me n random numbers", "give me n records from this database",
> etc. along similar lines.
>
> The difference between this and the current `Array(repeating:count:)`
> initializer is switching the arguments and using a trailing closure  (or an
> autoclosure) rather than a set value. That API was designed without the
> possibility that you might want to repeat a generator, so there's a bit of
> linguistic turbulence.
>
> -- E
>
>
To me at least, this is a very i-Centric complaint, since I can barely
remember the last time I needed something like this for anything that
didn’t involve UIKit. What you’re asking for is API sugar for generating
reference types with less typing. The problem is it’s hugely disruptive to
user’s mental model of how Swift operates, to say the least. When I read a
function signature like Array.init(count:object:) or whatever, I expect
that if a referency type is passed to the object parameter, the *pointer*
gets copied `count` times, and the reference count incremented accordingly.
I don’t expect the object itself to get deepcopied. That’s why the use of
@autoclosure is strongly recommended against
,
and why it only appears in things relating to debugging like
assert(condition:message:file:line:), which are mentally separated from the
rest of Swift.

Doing this with a function is less disruptive, but if you ask me, it
expands API surface area without offering any real benefit. As people have
pointed out, we already have a perfectly good idiom in (0 ..< n).map{ _ in
UIView() }. I never understood why certain people complain about
“discarding the domain”, but have no problem writing things like this:

for _ in 0 ..< n
{
//
}

If you’re truly allergic to map{ _ in UIView() }, might I suggest the
following:

var array:[UIView] = []
array.reserveCapacity(n)
for _ in 0 ..< n
{
{ array.append(UIView()) }()
}

That’s really all an array initializer that takes a block is really doing.
Or just use map.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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
function like `print(_:separator:terminator:)` or `
readLine(strippingNewline:)` to live anywhere but the standard library,
then it stands to reason that the stderr version should also live in the
standard library.

* Foundation is “supposed” to be the core library that does these things,
but this isn’t a good thing. Rationale:

* Foundation is literally an Objective C framework that’s written with
Swift syntax. The classes extend *NSObject*. You use them by *subclassing*
them and overriding open methods. This is patently unswifty. Even parts of
Foundation that look swifty on the outside (like `URL`) are still backed by
NS reference types internally.

* To fix this would require a complete rewrite from the ground up,
that’s more than a straight port from the Objective C framework. Many on
this list have also expressed desire to use this chance to redesign these
APIs. Since we’d basically have to rewrite all of it, any effort to
modernize Foundation is basically writing a new core library.

* Even if a piece of Foundation was rewritten like a real Swift
library, because of the monolith pattern, you still wind up importing a lot
of legacy code that shouldn’t be floating around your project. Using the
file system tools shouldn’t change `String`.

* Foundation’s file system capabilities are really just a class wrapper
around Glibc/Darwin functions. So in a way, Foundation is already a sort of
unified import for C, except it brings in a whole load of Objective C cruft
with it.

* Logically, this means in terms of the XY problem, Foundation is on
the Y side. Foundation is what happens if you rely on Swift’s C interop to
get the job done instead of building a true Swift solution, which would
involve Swift quarterbacking all the nasty system calls, instead of
Glibc/Darwin doing it.

In conclusion,

* What we need is a modern Swift solution for accessing file systems.

* What we have to do right now is leverage Swift’s C interop to use
Glibc/Darwin, while handing imports and platform inconsistencies manually.

* Eventually, the ideal would be for Swift to handle that in Swift, instead
of delegating to a platform-dependent C library, or at least standardize
things so that a swifty Swift library imports the right C library for you,
and exports a platform-independent set of symbols to the user, or a higher
level API.

* Foundation is in many ways the worst of both worlds. It handles the
Glibc/Darwin import for us, but at the cost of an aging framework that runs
against the grain of good Swift design idioms.

On Thu, Aug 17, 2017 at 8:16 PM, Xiaodi Wu  wrote:

> On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift 
> wrote:
>
>> I don’t think the “is this library functionality or standard library
>> functionality” argument is worth having, but if stdout and stdin are
>> first-class citizens in the Swift world, so should stderr.
>>
>> As for bringing Foundation into the discussion, you can’t really talk
>> about Foundation without also talking about the mountains of problems that
>> come with the monolith pattern. But that’s a completely different
>> conversation to be had.
>>
>
> I'm not sure what you're getting at here, but I don't believe you've
> addressed my question, which is: it's been firmly decided that I/O belongs
> in Foundation, and Foundation does in fact offer such facilities--what is
> missing from those facilities, and how can we fill it out?
>
>
> On Thu, Aug 17, 2017 at 7:13 PM, Xiaodi Wu  wrote:
>>
>>> IMO, you’re touching on at least three or four separate topics here.
>>> Daniel touched on several, but just some comments/questions:
>>>
>>> * Standard error output is something that’s been discussed here
>>> previously. I believe the last pitch had something like StandardError being
>>> added to the standard library as a TextOutputStream.
>>>
>>> * Foundation is supposed to be the core library that provides file
>>> system access facilities. What’s missing, and can we add it to Foundation?
>>>
>>> On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>> Python’s os.path <https://docs.python.org/2/library/os.path.html> is a
>>>> nice abstract model for doing path manipulations. Maybe Swift could get a
>>>> struct like `Filepath` or something on which these operations could be 
>>>> done.
>>>>
>>>> On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 

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

[Taylor Swift via swift-evolution]

I don’t think the “is this library functionality or standard library
functionality” argument is worth having, but if stdout and stdin are
first-class citizens in the Swift world, so should stderr.

As for bringing Foundation into the discussion, you can’t really talk about
Foundation without also talking about the mountains of problems that come
with the monolith pattern. But that’s a completely different conversation
to be had.

On Thu, Aug 17, 2017 at 7:13 PM, Xiaodi Wu  wrote:

> IMO, you’re touching on at least three or four separate topics here.
> Daniel touched on several, but just some comments/questions:
>
> * Standard error output is something that’s been discussed here
> previously. I believe the last pitch had something like StandardError being
> added to the standard library as a TextOutputStream.
>
> * Foundation is supposed to be the core library that provides file system
> access facilities. What’s missing, and can we add it to Foundation?
>
> On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Python’s os.path <https://docs.python.org/2/library/os.path.html> is a
>> nice abstract model for doing path manipulations. Maybe Swift could get a
>> struct like `Filepath` or something on which these operations could be done.
>>
>> On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift 
>> wrote:
>>
>>>
>>>
>>> On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar 
>>> wrote:
>>>
>>>>
>>>> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
>>>> swift-evolution@swift.org> wrote:
>>>> >
>>>> > I know this has come up before without any action, but having the
>>>> standard C library be packaged under `Darwin` on OSX and `Glibc` under
>>>> Linux is something that’s really becoming an issue as the Swift package
>>>> ecosystem matures. Right now a lot of packages are a lot less portable than
>>>> they could be because somewhere along the dependency line, there is a
>>>> package that only imports the C library for one platform. Unifying it under
>>>> one import would allow people to write packages that are portable by
>>>> default.
>>>>
>>>> What we (SwiftPM) have done for now is use a `libc` target to start by
>>>> normalizing the name:
>>>>   https://github.com/apple/swift-package-manager/tree/
>>>> master/Sources/libc
>>>> (and in the past, when we find missing things in Glibc getting them
>>>> added to the compiler). Also, this name is technically a misnomer, but we
>>>> couldn’t think of a better one (“os” might have been a good one).
>>>>
>>>> Unfortunately, I think this change alone is really only the tip of the
>>>> iceberg. It would be nice to not have it the difference, but we found we
>>>> very quickly needed several other layers on top to get to having a
>>>> relatively stable cross-platform base:
>>>>   https://github.com/apple/swift-package-manager/tree/
>>>> master/Sources/POSIX
>>>>   https://github.com/apple/swift-package-manager/tree/
>>>> master/Sources/Basic
>>>>
>>>> My hope is that one minimal improvement we can get soon is
>>>> multi-package repo support in SwiftPM, which will at least allow us to
>>>> share those targets & functionality with other packages.
>>>>
>>>> > Since I think this got hung up in the past over “what constitutes” a
>>>> universal libc, I propose a unified package should just consist of the
>>>> functionality that is common between Darwin and Glibc right now, since
>>>> those are the only two supported platforms anyway.
>>>>
>>>> What would the concrete proposal be? It isn’t trivial to determine that
>>>> subset and make it well-defined what the exact API is. Is the proposal to
>>>> just to pick a standard name, and reexport Darwin and Glibc from it?
>>>>
>>>
>>> I don’t know if it’s actually this simple, but could it just be the
>>> symbols that are defined in both modules?
>>>
>>>
>>>>
>>>> > Alternatively, Swift could make it a priority to get basic
>>>> functionality like file IO and math functions shipped with the compiler,
>>>> which would probably cover 98% of cases where people currently import
>>>> Darwin/Glibc. A large portion of the standard C libraries are redundant to
>>>> the Swift standard library anyway.
>

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

[Taylor Swift via swift-evolution]

Python’s os.path <https://docs.python.org/2/library/os.path.html> is a nice
abstract model for doing path manipulations. Maybe Swift could get a struct
like `Filepath` or something on which these operations could be done.

On Thu, Aug 17, 2017 at 6:47 PM, Taylor Swift  wrote:

>
>
> On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar 
> wrote:
>
>>
>> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I know this has come up before without any action, but having the
>> standard C library be packaged under `Darwin` on OSX and `Glibc` under
>> Linux is something that’s really becoming an issue as the Swift package
>> ecosystem matures. Right now a lot of packages are a lot less portable than
>> they could be because somewhere along the dependency line, there is a
>> package that only imports the C library for one platform. Unifying it under
>> one import would allow people to write packages that are portable by
>> default.
>>
>> What we (SwiftPM) have done for now is use a `libc` target to start by
>> normalizing the name:
>>   https://github.com/apple/swift-package-manager/tree/master/Sources/libc
>> (and in the past, when we find missing things in Glibc getting them added
>> to the compiler). Also, this name is technically a misnomer, but we
>> couldn’t think of a better one (“os” might have been a good one).
>>
>> Unfortunately, I think this change alone is really only the tip of the
>> iceberg. It would be nice to not have it the difference, but we found we
>> very quickly needed several other layers on top to get to having a
>> relatively stable cross-platform base:
>>   https://github.com/apple/swift-package-manager/tree/master/
>> Sources/POSIX
>>   https://github.com/apple/swift-package-manager/tree/master/
>> Sources/Basic
>>
>> My hope is that one minimal improvement we can get soon is multi-package
>> repo support in SwiftPM, which will at least allow us to share those
>> targets & functionality with other packages.
>>
>> > Since I think this got hung up in the past over “what constitutes” a
>> universal libc, I propose a unified package should just consist of the
>> functionality that is common between Darwin and Glibc right now, since
>> those are the only two supported platforms anyway.
>>
>> What would the concrete proposal be? It isn’t trivial to determine that
>> subset and make it well-defined what the exact API is. Is the proposal to
>> just to pick a standard name, and reexport Darwin and Glibc from it?
>>
>
> I don’t know if it’s actually this simple, but could it just be the
> symbols that are defined in both modules?
>
>
>>
>> > Alternatively, Swift could make it a priority to get basic
>> functionality like file IO and math functions shipped with the compiler,
>> which would probably cover 98% of cases where people currently import
>> Darwin/Glibc. A large portion of the standard C libraries are redundant to
>> the Swift standard library anyway.
>>
>> I’m not sure I agree with these statements about the percentages. For
>> some clients (I’m biased, the areas I work in tend to be in this boat),
>> what we largely need is good platform-agnostic access to the POSIX APIs.
>> This is a hard problem to make a good cross-platform API for (esp. if
>> Windows support is in your head), and which many projects struggle with
>> (Netscape :: NSPR, LLVM :: libSupport, many many more).
>>
>> The sticking point I see is this: if the proposal is just to unify the
>> name & that doesn’t actually buy us all that much (still need standard
>> layers on top), then have we really solved enough of a problem to be worth
>> standardizing on?
>>
>> +1 in general agreement with the meta-issue being an important one to
>> discuss.
>>
>
> There probably is an XY issue at play here; what we *really* need is a
> way to access the file system built into the standard library. (Math
> functions are a separate, beleaguered topic for a different thread.) Having
> support for outputting to `stderr` is also something I’d really like. Going
> through Glibc/Darwin is just one way to solve this.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar 
wrote:

>
> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I know this has come up before without any action, but having the
> standard C library be packaged under `Darwin` on OSX and `Glibc` under
> Linux is something that’s really becoming an issue as the Swift package
> ecosystem matures. Right now a lot of packages are a lot less portable than
> they could be because somewhere along the dependency line, there is a
> package that only imports the C library for one platform. Unifying it under
> one import would allow people to write packages that are portable by
> default.
>
> What we (SwiftPM) have done for now is use a `libc` target to start by
> normalizing the name:
>   https://github.com/apple/swift-package-manager/tree/master/Sources/libc
> (and in the past, when we find missing things in Glibc getting them added
> to the compiler). Also, this name is technically a misnomer, but we
> couldn’t think of a better one (“os” might have been a good one).
>
> Unfortunately, I think this change alone is really only the tip of the
> iceberg. It would be nice to not have it the difference, but we found we
> very quickly needed several other layers on top to get to having a
> relatively stable cross-platform base:
>   https://github.com/apple/swift-package-manager/tree/master/Sources/POSIX
>   https://github.com/apple/swift-package-manager/tree/master/Sources/Basic
>
> My hope is that one minimal improvement we can get soon is multi-package
> repo support in SwiftPM, which will at least allow us to share those
> targets & functionality with other packages.
>
> > Since I think this got hung up in the past over “what constitutes” a
> universal libc, I propose a unified package should just consist of the
> functionality that is common between Darwin and Glibc right now, since
> those are the only two supported platforms anyway.
>
> What would the concrete proposal be? It isn’t trivial to determine that
> subset and make it well-defined what the exact API is. Is the proposal to
> just to pick a standard name, and reexport Darwin and Glibc from it?
>

I don’t know if it’s actually this simple, but could it just be the symbols
that are defined in both modules?


>
> > Alternatively, Swift could make it a priority to get basic functionality
> like file IO and math functions shipped with the compiler, which would
> probably cover 98% of cases where people currently import Darwin/Glibc. A
> large portion of the standard C libraries are redundant to the Swift
> standard library anyway.
>
> I’m not sure I agree with these statements about the percentages. For some
> clients (I’m biased, the areas I work in tend to be in this boat), what we
> largely need is good platform-agnostic access to the POSIX APIs. This is a
> hard problem to make a good cross-platform API for (esp. if Windows support
> is in your head), and which many projects struggle with (Netscape :: NSPR,
> LLVM :: libSupport, many many more).
>
> The sticking point I see is this: if the proposal is just to unify the
> name & that doesn’t actually buy us all that much (still need standard
> layers on top), then have we really solved enough of a problem to be worth
> standardizing on?
>
> +1 in general agreement with the meta-issue being an important one to
> discuss.
>

There probably is an XY issue at play here; what we *really* need is a way
to access the file system built into the standard library. (Math functions
are a separate, beleaguered topic for a different thread.) Having support
for outputting to `stderr` is also something I’d really like. Going through
Glibc/Darwin is just one way to solve this.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

I know this has come up before without any action, but having the standard
C library be packaged under `Darwin` on OSX and `Glibc` under Linux is
something that’s really becoming an issue as the Swift package ecosystem
matures. Right now a lot of packages are a lot less portable than they
could be because somewhere along the dependency line, there is a package
that only imports the C library for one platform. Unifying it under one
import would allow people to write packages that are portable by default.

Since I think this got hung up in the past over “what constitutes” a
universal libc, I propose a unified package should just consist of the
functionality that is common between Darwin and Glibc right now, since
those are the only two supported platforms anyway.

Alternatively, Swift could make it a priority to get basic functionality
like file IO and math functions shipped with the compiler, which would
probably cover 98% of cases where people currently import Darwin/Glibc. A
large portion of the standard C libraries are redundant to the Swift
standard library anyway.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

Implementation is here: https://github.com/apple/swift/pull/11464

On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift  wrote:

> I’ve revised the proposal based on what I learned from trying to implement
> these changes. I think it’s worth tacking the existing methods that take
> Sequences at the same time as this actually makes the design a bit
> simpler.
> 
>
> *The previous version
>  of this
> document ignored the generic initialization methods on
> UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer, leaving them
> to be overhauled at a later date, in a separate proposal. Instead, this
> version of the proposal leverages those existing methods to inform a more
> compact API design which has less surface area, and is more future-proof
> since it obviates the need to design and add another (redundant) set of
> protocol-oriented pointer APIs later.*
>
> On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift 
> wrote:
>
>> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers
>> is ready for community review, and I encourage everyone to look it over and
>> provide feedback. Thank you!
>> > als/0184-improved-pointers.md>
>>
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

I’ve revised the proposal based on what I learned from trying to implement
these changes. I think it’s worth tacking the existing methods that take
Sequences at the same time as this actually makes the design a bit simpler.


*The previous version
 of this
document ignored the generic initialization methods on
UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer, leaving them
to be overhauled at a later date, in a separate proposal. Instead, this
version of the proposal leverages those existing methods to inform a more
compact API design which has less surface area, and is more future-proof
since it obviates the need to design and add another (redundant) set of
protocol-oriented pointer APIs later.*

On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift  wrote:

> Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers
> is ready for community review, and I encourage everyone to look it over and
> provide feedback. Thank you!
>  proposals/0184-improved-pointers.md>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

okay so I’m implementing <https://github.com/kelvin13/swift> this rn, and i
just realized that the functions
UnsafeMutableRawBufferPointer.initializeMemory(as:from:count:) and
UnsafeMutableRawBufferPointer.moveInitializeMemory(as:from:count:) are
gonna be a problem. Since they take a strided buffer pointer as its
argument, should they lose the count: argument and take the count value
from source.count? However, this would go opposite of the direction in most
of the typed buffer pointer methods, where count comes from self.count, not
source.count.

On Wed, Aug 9, 2017 at 11:51 AM, Taylor Swift via swift-evolution <
swift-evolution@swift.org> 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:
>>
>>>
>>> On Aug 8, 2017, at 8:44 PM, Taylor Swift  wrote:
>>>
>>> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot
>>> find such a function anywhere in the API. There is copyBytes(from:)
>>> <https://developer.apple.com/documentation/swift/unsafemutablerawbufferpointer/2635415-copybytes>,
>>> but the documentation is messed up and mentions a nonexistent count:
>>> argument over and over again. The documentation also doesn’t mention what
>>> happens if there is a length mismatch, so users are effectively relying on
>>> an implementation detail. I don’t know how to best resolve this.
>>>
>>>
>>> We currently have `UnsafeMutableRawBufferPointer.copyBytes(from:)`. I
>>> don’t think your proposal changes that. The current docs refer to the
>>> `source` parameter, which is correct. Docs refer to the parameter name, not
>>> the label name. So `source.count` is the size of the input. I was pointing
>>> out that it has the semantics: `debugAssert(source.count <= self.count)`.
>>>
>>> Your proposal changes `UnsafeRawPointer.copyBytes(from:count:)` to
>>> `UnsafeRawPointer.copy(from:bytes:)`. Originally we wanted to those API
>>> names to match, but I’m fine with your change. What is more important is
>>> that the semantics are the same as `copyBytes(from:)`. Furthermore, any new
>>> methods that you add that copy into a raw buffer (e.g.
>>> initializeMemory(as:from:count:)) should have similar behavior.
>>>
>>>
>> I’m fine with switching to taking the count from the source, though I
>> think taking the count from the destination is slightly better because
>> 1) the use cases I mentioned in the other email, and 2) all the other
>> memorystate functions use self.count instead of source.count, if they
>> take a source argument. But being consistent with the raw pointer
>> version is more important.
>>
>>
>> If it’s copying from a buffer it should not take a count, if it’s copying
>> from a pointer it obviously needs to take a count. What I mean by the two
>> versions being named consistently is simply that they’re both named
>> `copyBytes`. That really isn’t important though. The overflow/underflow
>> semantics being consistent are important.
>>
>> (Incidentally, the reason “bytes” needs to be in the somewhere name is
>> because this method isn’t capable of copying nontrivial values)
>>
>> Should the methods that don’t deal with raw buffers also be modified to
>> use the source argument (i.e. UnsafeMutableBufferPointer.ini
>> tialize(from:))?
>>
>>
>> I’m not sure what you mean by this. It also allows the destination to be
>> larger than the source. Initializing from a sequence does not trap on
>> overflow because we can’t guarantee the size of the sequence ahead of time.
>> When I talk about consistent overflow/underflow semantics, I’m only talking
>> about initializing one unsafe buffer/pointer from another unsafe
>> buffer/pointer.
>>
>> Also, was there a reason why UnsafeMutableRawBufferPointer.
>> copyBytes(from:) uses the source’s count instead of its own? Right now
>> this behavior is “technically” undocumented behavior (as the public docs
>> haven’t been updated) so if there was ever a time to change it, now would
>> be it.
>>
>>
>> Mainly because partial initialization is more expected than dropping data
>> on the floor. Ultimately, this should be whatever typical developers would
>> expect the behavior to be. I would be very hesitant to change the behavior
>> now though.
>>
>> -Andy
>>
>
> The problem is I would expect to be able to safely call deinitialize() and
> friends after calling initial

Re: [swift-evolution] How does "Sequence.joined" work?

[Taylor Swift via swift-evolution]

On Wed, Aug 9, 2017 at 10:43 AM, Daryle Walker via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 8, 2017, at 6:45 PM, Geordie Jay  wrote:
>
>
> Daryle Walker via swift-evolution  schrieb am
> Di. 8. Aug. 2017 um 21:25:
>
>> On Aug 8, 2017, at 12:35 AM, Félix Cloutier 
>> wrote:
>>
>> All this means is that `joined()` does not create an array that contains
>> the new result. It's only as magic as the COW semantics on arrays.
>>
>>
>> So you’re saying the COW semantics for Array and other standard library
>> types have secret references/pointers that work even for “let”-mode
>> objects, and the Sequence variants the various forms of “joined” need use a
>> Sequence/Collection of those secret references?
>>
>
> I know nothing about this specific type under the hood and your question
> stumped me when I first saw it as well, so take this with a grain of salt:
>
> I think it's basically just storing the arrays internally (as let) and
> when you iterate through the collection it just goes through the
> subsequences one by one, when the last index of the first is reached it
> begins with the next subsequence.
>
> As for how it avoids creating new storage, simple. As someone else
> mentioned, this is no more magic than Copy On Write for normal arrays.
>
> let a = [1,2,3]
> let b = a // this doesn't produce a copy of the underlying buffer.. I.e.
> value semantics but only one buffer needed
>
> ^^^ This is the take-home message. And your intuition about COW is
> correct: its internal storage is a reference type containing a buffer
> pointer. When (and only when) a mutation occurs, the buffer is copied and
> the new storage becomes the backing for the resulting struct. Any existing
> copies remain unchanged (and truly immutable) because they keep their
> original storage.
>
> https://github.com/apple/swift/blob/master/stdlib/public/core/
> ContiguousArrayBuffer.swift
>
>
> So with that understanding of COW, it becomes easy to imagine all sorts of
> containers that don't require additional storage for their contents:
>
> struct JoinedSequenceOfThreeArrays {
>   let array1: [T]
>   let array2: [T]
>   let array3: [T]
> }
>
> // still only one array buffer storage is required for all of this:
> let c = JoinedSequenceOfThreeArrays(array1: a, array2: a, array3: b)
>
> Does that make sense?
>
>
> Mostly, then I realized a flaw with this explanation. Your theory implies
> that “joined” avoids creating new storage by betraying that and actually
> copying the containers, but said containers use-COW/reference-remote-storage
> themselves. Then what happens when a Sequence uses scoped storage for its
> items? (Example: the mythical “just slap Collection on a tuple and call it
> an array” type.) Either “joined” uses a different no-copy technique or it’s
> lying about saving on storage (and the lack of scoped-storage Sequences
> means no one has called them on it yet).
>

I don’t see any contradiction here. A tuple is a value type; it has no
concept of copy-on-write because it’s copy-on-read. So JoinedSequence will
store a copy of the tuple instead of a buffer reference
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

[Taylor Swift via swift-evolution]

On Wed, Aug 9, 2017 at 5:54 AM, Daniel Vollmer via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 9. Aug 2017, at 06:51, Taylor Swift via swift-users <
> swift-us...@swift.org> wrote:
> >
> > It’s possible to implement a classic red-black tree in Swift that
> performs better than a sorted Array, down to about n = 1,500 items, not n =
> 100,000 items as it claims. (Actually, heap allocators these days are good
> enough that performance is on par with Array all the way down to n = 1.)
>
> I’m not sure how that can be because you lose locality (but that probably
> depends on what operations “perform” includes). And IMO, heap allocations
> remain (and will remain) a bottleneck for small allocations.
>
> Daniel.
> ___
>
>
If the number of nodes is small, Swift’s heap allocator will actually place
then contiguously in memory, just like an Array, as long as you don’t wait
too long between calls to insert(_:). You can also write your own simple
memory allocator in Swift that’s backed by an Array which guarantees the
nodes will live near each other in memory. But that’s getting off topic lol
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Taylor Swift via swift-evolution]

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:
>
>>
>> On Aug 8, 2017, at 8:44 PM, Taylor Swift  wrote:
>>
>> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot
>> find such a function anywhere in the API. There is copyBytes(from:)
>> ,
>> but the documentation is messed up and mentions a nonexistent count:
>> argument over and over again. The documentation also doesn’t mention what
>> happens if there is a length mismatch, so users are effectively relying on
>> an implementation detail. I don’t know how to best resolve this.
>>
>>
>> We currently have `UnsafeMutableRawBufferPointer.copyBytes(from:)`. I
>> don’t think your proposal changes that. The current docs refer to the
>> `source` parameter, which is correct. Docs refer to the parameter name, not
>> the label name. So `source.count` is the size of the input. I was pointing
>> out that it has the semantics: `debugAssert(source.count <= self.count)`.
>>
>> Your proposal changes `UnsafeRawPointer.copyBytes(from:count:)` to
>> `UnsafeRawPointer.copy(from:bytes:)`. Originally we wanted to those API
>> names to match, but I’m fine with your change. What is more important is
>> that the semantics are the same as `copyBytes(from:)`. Furthermore, any new
>> methods that you add that copy into a raw buffer (e.g.
>> initializeMemory(as:from:count:)) should have similar behavior.
>>
>>
> I’m fine with switching to taking the count from the source, though I
> think taking the count from the destination is slightly better because 1)
> the use cases I mentioned in the other email, and 2) all the other
> memorystate functions use self.count instead of source.count, if they
> take a source argument. But being consistent with the raw pointer version
> is more important.
>
>
> If it’s copying from a buffer it should not take a count, if it’s copying
> from a pointer it obviously needs to take a count. What I mean by the two
> versions being named consistently is simply that they’re both named
> `copyBytes`. That really isn’t important though. The overflow/underflow
> semantics being consistent are important.
>
> (Incidentally, the reason “bytes” needs to be in the somewhere name is
> because this method isn’t capable of copying nontrivial values)
>
> Should the methods that don’t deal with raw buffers also be modified to
> use the source argument (i.e. UnsafeMutableBufferPointer.
> initialize(from:))?
>
>
> I’m not sure what you mean by this. It also allows the destination to be
> larger than the source. Initializing from a sequence does not trap on
> overflow because we can’t guarantee the size of the sequence ahead of time.
> When I talk about consistent overflow/underflow semantics, I’m only talking
> about initializing one unsafe buffer/pointer from another unsafe
> buffer/pointer.
>
> Also, was there a reason why UnsafeMutableRawBufferPointer.
> copyBytes(from:) uses the source’s count instead of its own? Right now
> this behavior is “technically” undocumented behavior (as the public docs
> haven’t been updated) so if there was ever a time to change it, now would
> be it.
>
>
> Mainly because partial initialization is more expected than dropping data
> on the floor. Ultimately, this should be whatever typical developers would
> expect the behavior to be. I would be very hesitant to change the behavior
> now though.
>
> -Andy
>

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. That being said, since copy(from:bytes:) and copyBytes(from:)
don’t do any initialization and have no direct counterparts in
UnsafeMutableBufferPointer, it’s okay if they have different behavior than
the other methods.


>
> —
>>
>> Another thing. The initialization methods that you’re adding to
>> `UnsafeRawPointer` and `UnsafeRawBufferPointer` should return typed
>> `UnsafePointer` and `UnsafeBufferPointer` respectively.
>>
>
> I’ll fix that once the current pending edit
>  gets merged.
>
>
>>
>> Thanks,
>>
>> -Andy
>>
>> On Tue, Aug 8, 2017 at 11:33 PM, Andrew Trick  wrote:
>>
>>>
>>> On Aug 8, 2017, at 8:29 PM, Taylor Swift  wrote:
>>>
>>>
>>>
>>> On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick  wrote:
>>>

 On Aug 8, 2017, at 6:51 PM, Taylor Swift  wrote:



 On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick  wrote:

>
> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:)
>>
>> Well, I think it's somewhat ridiculous for users to write this every
>> time they allocate a buffer:
>>
>> `UnsafeMutableRawBufferPointer.allocate(bytes: size, alignedTo:
>> MemoryLayout.align