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

[Kelvin Ma via swift-evolution]

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

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 <
> swift-evolution@swift.org> 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 <
> swift-evolution@swift.org> 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 <
> swift-evolution@swift.org> 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 <
> swift-evolution@swift.org> 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
>
> 

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

[Kelvin Ma via swift-evolution]

On Tue, Jan 9, 2018 at 5:12 AM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> Some thoughts:
>
> - How do I randomly select an enum?
>

carefully, of course


>
> - I like that RandomNumberGenerator doesn’t have an associated type. I
> agree that we should just spit out UInt64s for simplicity.
>
> - I don’t like how it is so closely tied with Range.  I realize that both
> Int and Float work with Ranges, but other random types do not (e.g.
> CGVectors).  You are special casing FixedWidthInteger and
> BinaryFloatingPoint, which are very important… but we lose the ability to
> deal with other randomly generated types.
>

generating “random vectors” is a *big* mood and it’s not as simple as
varying on a range of *R*3. There’s a mild but non-trivial amount of work
needed to get a uniform distribution and avoid degeneracies and division by
zero. and “random” can mean different things, sometimes you want a random
2D disk of vectors that all live in some plane in 3D space because you need
them to be perpendicular to something. And at any rate, CGVector is not a
standard type, while Int and Float are.


>
> - Following on the previous point, I don’t like that the code for dealing
> with Integers/Floats is in Range.  It feels like things aren’t properly
> encapsulated.
>
> - Why bother supporting non-closed Ranges at all?  If you only allow
> closed ranges, then you can’t end up with an empty range. The only
> difference in behavior I can think of is on floating point, but I can’t
> think of a use-case where excluding the supremum is actually useful in any
> real world way.
>

i see this as an inconvenience for the sake of security theater. Usually
when you want a random integer on a continuous range, you’re using them as
indices into something. And indices go from 0 ..< count, not 0 ... (count -
1). if whatever you’re indexing into is empty, it’s empty.


>
> - This may sound strange, but I would *really* like to see Bool handled
> as a default implementation on the generator protocol itself.  On my own
> version of this I have both the ‘coinFlip()’ and ‘oneIn(_ num:Int)’ methods
> which I find extremely useful.  CoinFlip just gives you a random bool,
> whereas you can say things like oneIn(100) to get ‘true’ roughly 1 out of
> every 100 times you call it.  These are useful for branching randomly.
> They are most useful on the source/generator itself because it is ergonomic
> when you need to rewind the source.
>
> - IMO distributions should be sources/generators themselves which just
> wrap another source.  We could have a subprotocol of RandomNumberGenerator
> which just semantically guarantees uniform distribution, and then
> distributions that need it could be sure of the input distribution.  Notice
> this doesn’t limit the distribution to only be used for Integers as they
> are in the demo. They can be used anywhere a source can be used.
>
> - Having a subprotocol for generators which can be rewound is extremely
> important for entire classes of real-world problems.  I have spent a lot of
> time using this and it solves a LOT of problems. For example, I have a
> Lorem Ipsum Generator which takes Attributes and a CGSize to fill.  It
> works by branching (using the Bool methods above) and then rewinding bits
> which don’t fit (If you just futz with the last part instead of generating
> appropriate clauses, it won’t look right).  I also have a bunch of
> backtracking algorithms which rely on this rewind ability.  Plus numerous
> visual effects which rely on a repeatable rewindable source.
> *- Tl;dr: It isn’t enough to just have a seed, you need to be able to mark
> a state of a generator and return to that state later.*
>
> My RepeatableRandomSource Protocol has 3 extra methods:
> - It takes a seed
> - It has a mark() method which returns a token
> - It has a returnToMark(_ mark:Mark) method which takes a token and
> restores the appropriate state
>
> - I really appreciate that you made a playground :-)
>
> Thanks,
> Jon
>
>
> On Jan 8, 2018, at 11:02 AM, Nate Cook via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I created a playground to explore this question, starting with a minimal
> subset of the proposal’s additions and building from there. The attached
> playground demonstrates what’s possible with this subset on the first page,
> then uses subsequent pages to explore how the main random facilities of the
> C++ STL work under this model. (In my opinion, they work pretty well!)
>
> The subset in the playground has three main differences from the proposal:
>  - It doesn't include a Randomizable protocol or a random property on
> numeric types.
>  - It doesn't include the static random(in:) methods on numeric types,
> either.
>  - The RandomNumberGenerator protocol doesn't have an associated type.
> Instead, it requires all conforming types to produce UInt64 values.
>
> I’ve tried to include a bit of real-world usage in the playground to
> demonstrate what writing code 

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

[Kelvin Ma via swift-evolution]

On Tue, Jan 2, 2018 at 11:45 PM, Nevin Brackett-Rozinsky via
swift-evolution  wrote:

> On Tue, Jan 2, 2018 at 9:07 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> [Proposal: https://github.com/apple/swift-evolution/blob/mas
>> ter/proposals/0192-non-exhaustive-enums.md]
>>
>> Whew! Thanks for your feedback, everyone. On the lighter side of
>> feedback—naming things—it seems that most people seem to like '*@frozen*',
>> and that does in fact have the connotations we want it to have. I like it
>> too.
>>
>> More seriously, this discussion has convinced me that it's worth
>> including what the proposal discusses as a *'future' case*. The key
>> point that swayed me is that this can produce a *warning* when the
>> switch is missing a case rather than an *error,* which both provides the
>> necessary compiler feedback to update your code and allows your
>> dependencies to continue compiling when you update to a newer SDK. I know
>> people on both sides won't be 100% satisfied with this, but does it seem
>> like a reasonable compromise?
>>
>> The next question is how to spell it. I'm leaning towards `unexpected
>> case:`, which (a) is backwards-compatible, and (b) also handles "private
>> cases", either the fake kind that you can do in C (as described in the
>> proposal), or some real feature we might add to Swift some day. `unknown
>> case:` isn't bad either.
>>
>> I too would like to just do `unknown:` or `unexpected:` but that's
>> technically a source-breaking change:
>>
>> switch foo {
>> case bar:
>>   unknown:
>>   while baz() {
>> while garply() {
>>   if quux() {
>> break unknown
>>   }
>> }
>>   }
>> }
>>
>>
>> Another downside of the `unexpected case:` spelling is that it doesn't
>> work as part of a larger pattern. I don't have a good answer for that one,
>> but perhaps it's acceptable for now.
>>
>> I'll write up a revision of the proposal soon and make sure the core team
>> gets my recommendation when they discuss the results of the review.
>>
>> ---
>>
>> I'll respond to a few of the more intricate discussions tomorrow,
>> including the syntax of putting a new declaration inside the enum rather
>> than outside. Thank you again, everyone, and happy new year!
>>
>> Jordan
>>
>
>
> +1 to warning instead of error
> +1 to unknown/unexpected case
> +1 to “@frozen” or any other reasonable spelling, they are all fine by me.
>

+1 to “@tangled” because abi is complicated


>
> The one remaining problem to solve is making sure multi-module apps can
> leave out the unknown/unexpected case on enums from modules which are part
> of the app itself and thus cannot be updated independently of it. John
> McCall’s version-locking plan sounds promising, though we should explore
> the available options before finalizing a course.
>
> Perhaps we need a concept of submodules, or supermodules, or some other
> way to demarcate the boundaries of a resilience domain.
>
> Nevin
>

i would support a proper submodule system over some verson-locking system
that only the most advanced users will probably know about. i think modules
should be one level higher than what they’re currently being used for right
now for lack of a better alternative (one application should never have to
define more than one capital M Module). submodules shouldn’t be that hard
to implement, though the submodule names should be part of ABI to avoid
name mangling problems
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] why cant you initialize BinaryFloatingPoint from BinaryInteger?

[Kelvin Ma via swift-evolution]

title says it all,, this is kind of annoying when writing some generic
FloatingPoint code where both the integral and floating parameters are
unfixed.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-users] Happy new year Swift community.

[Kelvin Ma via swift-evolution]

Happy new year from klossyland!

On Mon, Jan 1, 2018 at 11:23 AM, Georgios Moschovitis via swift-users <
swift-us...@swift.org> wrote:

> Happy new year! Greetings from Cyprus :)
>
> George.
>
> On 1 Jan 2018, at 1:42 AM, Adrian Zubarev via swift-users <
> swift-us...@swift.org> wrote:
>
> Well some of you guys have to wait a little longer, but I can already wish
> everyone a happy new year from Germany. 🎉🎊🎆🎇
>
> --
> Adrian Zubarev
> Sent with Airmail
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>
> ___
> swift-users mailing list
> swift-us...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] namespacing protocols to other types

[Kelvin Ma via swift-evolution]

On Fri, Dec 29, 2017 at 11:20 PM, Eneko Alonso 
wrote:

> Modules do more than that. For instance, if two imported modules provide a
> type with the same name, you can distinguish (name-spacing) them by using
> ModuleA.Thing vs ModuleB.Thing.
>
> In regards of Modules being intended to be shipped separately, that is
> incorrect. You might be thinking of packages.
>

> In Swift 4, a package can contain multiple binaries, including executables
> and libraries. These, can be composed of one or many modules.
>
> Swift Package Manager handles this really well, and allows to organize the
> code separating it by features or concerns.
>

the Swift language itself has no concept of packages. packages are a thing
that the SPM creates and manages and downloads for you. the modules inside
a package actually have internal dependencies between each other which is
why you have to write them all out in Package.swift. but you can distribute
a package with modues that are decoupled from one another and another app
or library can import that one module and not all the others (though the
SPM will still download all of them for some reason.)


>
> I understand Xcode does not have very good support for modules yet, other
> than importing frameworks. But it is my understanding this is something the
> new Xcode’s build system will solve, hopefully by Xcode 10.
>
> I’m not against nesting protocol definitions, I can see a few cases where
> it could be nice to have them. But in regards of namespacing, I think using
> nested types is the wrong direction.
>

the Swift standard library (the actual stdlib not Foundation) actually uses
this system like Unicode
<https://developer.apple.com/documentation/swift/unicode> and CommandLine
<https://developer.apple.com/documentation/swift/commandline>.


>
> Thank you,
> Eneko Alonso
>
> On Dec 29, 2017, at 19:00, Kelvin Ma  wrote:
>
> Modules in Swift are really designed for code that is intended to be
> shipped separately. as Jon found out modules are pretty heavyweight and
> introduce a lot of unwanted abstraction and complexity when all you want to
> do is write things in a namespace. (Also if you forgot, importing a module
> in Swift dumps all of its symbols into the global namespace so
> Module.Thing is really meaningless.) sometimes this is a good thing
> because no one wants to be writing Glibc.fopen over and over especially
> when you have to #if #endif it out every time with Darwin.fopen if you
> want your library to run on OSX but this feature also makes modules
> ineffective as a namespacing scheme.
>
> On Fri, Dec 29, 2017 at 8:35 PM, Eneko Alonso 
> wrote:
>
>> …all i wanted to do was write Thing:Namespace.Protocol
>>
>>
>> Have you thought of using Swift modules for that? Maybe that would be a
>> better approach than trying to name-space within a module?
>>
>> Regards,
>> Eneko Alonso
>>
>> On Dec 29, 2017, at 16:51, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> …all i wanted to do was write Thing:Namespace.Protocol
>>
>> On Thu, Dec 28, 2017 at 4:43 PM, Adrian Zubarev via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Well again I don’t think we should disallow capturing the outer generic
>>> type parameter just because you cannot use the protocol inside the outer
>>> type atm., you still can add a type-eraser. To be honest such usage of the
>>> existential is not even a requirement for the outer type. On there other
>>> hand we might want to set the default for the associated type like I showed
>>> in my previous message. The nested protocol could serve a completely
>>> different purpose. Furthermore I still think that Generic.P and
>>> Generic.P should be distinct protocols just like nested generic and
>>> non-generic types are within an outer generic type. Sure there could be
>>> other problems with ambiguity if you think of something like
>>> GenericViewController.Delegate, but the disambiguation when
>>> conforming to such protocols requires a different solution and is a well
>>> known limitation today.
>>>
>>> That said you won’t design such nested types anyways if you know the
>>> existing language limitation. I’d say let’s keep it simple in theory and
>>> just align the nesting behaviour.
>>>
>>> About existentials:
>>>
>>> For that scenario I can only speak for myself. I wouldn’t want to allow
>>> directly the where clause existentials like this. It is far better and
>>> more readable when we force the where clause on typealiases instead. We
>>> could lift that res

Re: [swift-evolution] namespacing protocols to other types

[Kelvin Ma via swift-evolution]

Modules in Swift are really designed for code that is intended to be
shipped separately. as Jon found out modules are pretty heavyweight and
introduce a lot of unwanted abstraction and complexity when all you want to
do is write things in a namespace. (Also if you forgot, importing a module
in Swift dumps all of its symbols into the global namespace so Module.Thing
is really meaningless.) sometimes this is a good thing because no one wants
to be writing Glibc.fopen over and over especially when you have to #if
#endif it out every time with Darwin.fopen if you want your library to run
on OSX but this feature also makes modules ineffective as a namespacing
scheme.

On Fri, Dec 29, 2017 at 8:35 PM, Eneko Alonso 
wrote:

> …all i wanted to do was write Thing:Namespace.Protocol
>
>
> Have you thought of using Swift modules for that? Maybe that would be a
> better approach than trying to name-space within a module?
>
> Regards,
> Eneko Alonso
>
> On Dec 29, 2017, at 16:51, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> …all i wanted to do was write Thing:Namespace.Protocol
>
> On Thu, Dec 28, 2017 at 4:43 PM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Well again I don’t think we should disallow capturing the outer generic
>> type parameter just because you cannot use the protocol inside the outer
>> type atm., you still can add a type-eraser. To be honest such usage of the
>> existential is not even a requirement for the outer type. On there other
>> hand we might want to set the default for the associated type like I showed
>> in my previous message. The nested protocol could serve a completely
>> different purpose. Furthermore I still think that Generic.P and
>> Generic.P should be distinct protocols just like nested generic and
>> non-generic types are within an outer generic type. Sure there could be
>> other problems with ambiguity if you think of something like
>> GenericViewController.Delegate, but the disambiguation when
>> conforming to such protocols requires a different solution and is a well
>> known limitation today.
>>
>> That said you won’t design such nested types anyways if you know the
>> existing language limitation. I’d say let’s keep it simple in theory and
>> just align the nesting behaviour.
>>
>> About existentials:
>>
>> For that scenario I can only speak for myself. I wouldn’t want to allow
>> directly the where clause existentials like this. It is far better and
>> more readable when we force the where clause on typealiases instead. We
>> could lift that restriction later if we’d like to, but not the other way
>> around. I think it’s okay if we start with a small restriction first and
>> see if it adopts well (this is MHO), because this way it shouldn’t harm
>> anybody.
>>
>>
>>
>>
>> Am 28. Dezember 2017 um 21:51:29, Karl Wagner (razie...@gmail.com)
>> schrieb:
>>
>>
>>
>> On 28. Dec 2017, at 12:34, Adrian Zubarev > om> wrote:
>>
>> I disagree with some of your points. Do begin with, I don’t think we
>> should disallow capturing the generic type parameter, because I think there
>> might be a good way to prevent parameterization of nested protocols.
>>
>> To me this only feels like a natural consequence of nesting protocols
>> anyways. To achieve this we have to provide an explicit associated type
>> which will have a default type that refers to the captured outer generic
>> type parameter. At this point we discover another issue that we cannot
>> disambiguate generic type parameter like associated types yet and would be
>> forced to name the associated type of the protocol differently.
>>
>> struct Generic {
>>   protocol P {
>> associatedtype R = T
>> func f() -> R
>>   }
>> }
>>
>> As you can see I didn’t include the variable in this example, because
>> existential are orthogonal this issue. David Hart and I still want to write
>> a proposal to allow the where clause on typealiases - maybe after the
>> forum officially launches.
>>
>> Above I said that there is an issue and provided an example that would
>> solve that issue with todays syntax, but I’d rather expand this idea.
>> Consider this syntax of a generic type and a protocol with an associated
>> type.
>>
>> protocol Proto {
>>   associatedtype Element
>> }
>>
>> Proto.Element // This is an error like this, but it's still allowed in a 
>> generic context
>>
>> func function(_: P) where P.Element == Int {}
>>
>> protocol OtherProto : Pr

Re: [swift-evolution] namespacing protocols to other types

[Kelvin Ma via swift-evolution]

t; different implementations. You would likely end up having to separate the
> conformances by using a wrapper struct — in which case, why not just make
> them the same protocol and have the existing duplicate-conformance rules
> take care of it?
>
> An earlier version of the proposal included something like you describe.
> Basically, Generic.P and Generic.P would be the same protocol.
> They would have an associated type to represent the parameter from
> Generic, and within Generic, all references to P would be implicitly
> constrained so that P.T == Self.T. You would write conformances to
> “Generic.P” with a constraint for T, as you do today.
>
> And for the existential variable inside Genric it really should be
> something like this (when the where clause is allowed and if we can refer
> differently to generic type parameters as well):
>
> struct Generic {
> …
> typealias PConstrainedByT = P where T == Self.T
> var object: PConstrainedByT
> }
>
>
> If we have that ability, then we can totally do capturing. Forgive me, but
> I understand that as pretty-much the same as generalised existentials
> (without local type binding).
> If I can write the type of object as an existential of (generic protocol +
> constraints) via a typealias, then surely I must also be able to do it
> directly? So I could also write:
>
> struct Generic {
> var object: P where T == Self.T
> }
>
> Anyway, I thought that was not on the table, and in any case I’m convinced
> that it should be a separate proposal. This gets to the heart of the
> interaction between generic types and protocols, and we all know it’s not
> always a smooth transition (hello AnyCollection, AnyHashable, etc...). We
> can cover the common cases (i.e. the Apple frameworks) without requiring
> capturing - especially since it’s apparently not too difficult to implement
> - and build from there.
>
> - Karl
>
>
>
>
> Am 27. Dezember 2017 um 19:53:36, Karl Wagner via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Yeah I wrote that proposal. I eventually stripped it down to just disallow
> all capturing, but it was still not selected by the core team for review
> ¯\_(ツ)_/¯
>
> As for capturing semantics, once you start working through use-cases, it’s
> becomes clear that it's going to require generalised existentials.
> Otherwise, how would you use a Generic.P?
>
> struct Generic {
> protocol P { func f() -> T }
>
> var object: P // uh-oh! ‘Generic protocol can only be used as a
> generic parameter constraint'
> }
>
> So, you would need to add a generic parameter to actually *use* P from
> within Generic, which of course limits you to a single concrete type of
> P:
>
> struct Generic where TypeOfP: Self.P {  // Could this even
> work? What if P captures TypeOfP?
> protocol P { /* … */ }
> var object: TypeOfP
> }
>
> Which is just yucky.
>
> Ideally, the type of ‘object’ should be ‘Any’, to
> express that it can be any conforming type with the appropriate
> constraints. You wouldn’t need to write that all out; we could infer that
> capturing is equivalent to a same-type constraint (or perhaps one of these
> “generalised supertype constraints” that were pitched recently). But we
> can’t express those kinds of existentials everywhere in the type-system
> today, so most examples of capturing fall down pretty quickly.
>
> - Karl
>
> On 25. Dec 2017, at 03:56, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> There was a proposal to allow protocols to be nested inside types at one
> point but it didn’t move forward.
>
> Basically, if the outer type is a non-generic class, struct or enum,
> there’s no conceptual difficulty at all.
>
> If the outer type is a generic type or another protocol, you have a
> problem where the inner protocol can reference generic parameters or
> associated types of the outer type. This would either have to be banned, or
> we would need to come up with coherent semantics for it:
>
> struct Generic {
>  protocol P {
>func f() -> T
>  }
> }
>
> struct Conforms : Generic.P {
>  func f() -> Int { … } // Like this?
> }
>
> let c = Conforms()
> c is Generic.P // is this false? Ie, are Generic.P and
> Generic.P different protocols?
>
> Slava
>
> On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> is there a reason why it’s not allowed to nest a protocol declaration
> inside another type?
> ___
> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Kelvin Ma via swift-evolution]

that’s why i keep saying we should separate human-facing encapsulation
concepts from compiler-facing abi visibility concepts. i’ve always been
advocating for something like

internal(visible)
fileprivate(visible)
private(visible)

in the same spelling we currently use for stuff like private(set). we might
have to disallow it for fileprivate because of the name mangling issue that
Slava mentioned but it’s an elegant spelling and extensible if someone
comes up with a good unique mangling scheme for private declarations.

On Fri, Dec 29, 2017 at 10:35 AM, Félix Cloutier via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree with the common theme that `@abiPublic` is weird. I imagine that
> not a lot of `@abiPublic` symbols actually want to be internal: they'll
> almost all be implementation details that really want to be `private` or
> `fileprivate` but that have to be `internal` to satisfy what (I believe)
> most people would consider to be a leaky abstraction provided by the Swift
> language. So why not go all the way and force @inlinable code to only
> reference public declarations?
>
> What do we get in exchange of subverting the thus-far clear meaning of
> `internal`? Why is it better to have a special kind of internal that is not
> internal, instead of a special kind of public that is not listed, or even
> just no special kind of public?
>
> That detail aside, having the ability to do cross-module inlining and
> specializing is valuable and exciting.
>
> Félix
>
> Le 20 déc. 2017 à 19:19, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> The review of "SE-0193 - Cross-module inlining and specialization" begins
> now and runs through *January 5, 2018*.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0193-cross-module-inlining-and-specialization.md
>
> Reviews are an important part of the Swift evolution process. All review
> feedback 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/
> proposals/0193-cross-module-inlining-and-specialization.md
> ...
> Reply text
> ...
> Other replies
>
> What goes into a review of a proposal?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift.
>
> When reviewing a proposal, here are some questions to consider:
>
>-
>
>What is your evaluation of the proposal?
>-
>
>Is the problem being addressed significant enough to warrant a change
>to Swift?
>-
>
>Does this proposal fit well with the feel and direction of Swift?
>-
>
>If you have used other languages or libraries with a similar feature,
>how do you feel that this proposal compares to those?
>-
>
>How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> Thanks,
> Ted Kremenek
> Review Manager
>
> ___
> 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] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Kelvin Ma via swift-evolution]

yeah among people i know most ios updates are accidental. unless you count
the one time my friend updated because her phone automatically downloaded
the iso and it was taking up like 5 gb and she had no space left. the last
times i remember anyone willingly updating their iphone was the ios7 update
and the one that gave us all the new emojis. personally mine’s been
pestering me about ios 11.2.1 for a long ass time and i’m actually
relatively good about updating ios because people don’t get the echo text
effect when i send it. also i’m sure the apple slowing down old iphones
news isn’t helping much lol

On Mon, Dec 25, 2017 at 4:19 AM, Jean-Daniel  wrote:

> Look like we don’t know the same users.
> I don’t know a single user that didn’t update it’s device at least once
> since he bought it, even if some may avoid the latest update when there
> device grow old though.
>
> Le 25 déc. 2017 à 05:46, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> in theory this could happen but if you ask me this is such an exceedingly
> rare case that i don’t count much net benefit from it. most ithing users
> (that i know) avoid ios updates like hell but have automatic app updates
> turned on. so 99% of the time i would expect the app version to be more
> recent than the library version.
>
> On Sun, Dec 24, 2017 at 9:59 PM, Slava Pestov  wrote:
>
>>
>>
>> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> why can’t we just remove inlineable functions from ABI altogether? if the
>> argument is that app code won’t be able to take advantage of improved
>> implementations in future library versions i don’t think that makes sense
>> at all i would assume client code gets recompiled much more often than
>> library code and their updates are much more likely to be downloaded by
>> users than library updates.
>>
>>
>> This is not necessarily true. If Swift were to ship with the OS, updating
>> the OS might install a new Swift standard library without updating all of
>> your apps.
>>
>> Slava
>>
>>
>> On Sun, Dec 24, 2017 at 6:04 PM, Howard Lovatt via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Proposal link: https://github.com/apple/swift-evolution/blob/master/p
>>> roposals/0193-cross-module-inlining-and-specialization.md
>>>
>>>-
>>>
>>>What is your evaluation of the proposal?
>>>
>>>-1
>>>
>>>The proposal puts all the emphasis on the programmer. It is better
>>>for the compiler to decide if something is to be inclined both across
>>>modules and within modules.
>>>
>>>If something is made public then it should be fixed for a given
>>>major version number. No need for extra annotation.
>>>
>>>A module system that allows versioning is a better solution.
>>>-
>>>
>>>Is the problem being addressed significant enough to warrant a
>>>change to Swift?
>>>
>>>Yes significant but wrong solution
>>>-
>>>
>>>Does this proposal fit well with the feel and direction of Swift?
>>>
>>>No, cluttering up declarations is completely against the clarity of
>>>Swift. For example who other than people on this group will understand
>>>@inline(never) @inlinable.
>>>-
>>>
>>>If you have used other languages or libraries with a similar
>>>feature, how do you feel that this proposal compares to those?
>>>
>>>Yes C and C++ and found the equivalent of these annotations
>>>problematic. In Java they eliminated all this and let the compiler do the
>>>work. In practice this works much better.
>>>
>>>Perhaps the compiler should publish the SIL or LLVM for all public
>>>functions. Analogous to Java’s class files. This sort of system works
>>>really will, much better than C and C++.
>>>-
>>>
>>>How much effort did you put into your review? A glance, a quick
>>>reading, or an in-depth study?
>>>Followed the discussions and read the proposal. The proposal doesn’t
>>>seem to encompass all the discussions. It would be nice if the proposal 
>>> had
>>>a much more extensive summary of alternatives suggested.
>>>
>>> -- Howard.
>>>
>>> On 20 Dec 2017, at 7:19 pm, Ted Kremenek via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>&g

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Kelvin Ma via swift-evolution]

aren’t there other benefits to dynamic linking though? i’m not arguing
against dynamic linking, i’m arguing that functions that should be part of
ABI should *always* be called through the entry point and functions that
can be emitted into the client should *never* be called through the entry
point. otherwise it introduces complexity and potential bugs and internally
inconsistent behavior for no obvious benefit. the only reason inlineable
exists is for performance. a library author who marks something inlineable
and then tries to make the implementation itself more efficient is not
going to see much benefit from it just by pushing out the updated library
because no one is going to have the updated library on their device anyway.
we might as well follow Swift’s safety paradigm and make it consistent. as
for security, those functions should never have been marked inlineable to
begin with because even if a new implementation is available (and it won’t)
it doesn’t mean all the call sites will use the updated version.

On Sun, Dec 24, 2017 at 11:49 PM, Slava Pestov  wrote:

> Sure, users download new apps more often than they download new OSes, but
> you’re basically arguing against dynamic linking at this point. If
> everything was statically linked, vendors would not be able to ship
> security updates, etc.
>
> Slava
>
>
> On Dec 24, 2017, at 8:46 PM, Kelvin Ma  wrote:
>
> in theory this could happen but if you ask me this is such an exceedingly
> rare case that i don’t count much net benefit from it. most ithing users
> (that i know) avoid ios updates like hell but have automatic app updates
> turned on. so 99% of the time i would expect the app version to be more
> recent than the library version.
>
> On Sun, Dec 24, 2017 at 9:59 PM, Slava Pestov  wrote:
>
>>
>>
>> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> why can’t we just remove inlineable functions from ABI altogether? if the
>> argument is that app code won’t be able to take advantage of improved
>> implementations in future library versions i don’t think that makes sense
>> at all i would assume client code gets recompiled much more often than
>> library code and their updates are much more likely to be downloaded by
>> users than library updates.
>>
>>
>> This is not necessarily true. If Swift were to ship with the OS, updating
>> the OS might install a new Swift standard library without updating all of
>> your apps.
>>
>> Slava
>>
>>
>> On Sun, Dec 24, 2017 at 6:04 PM, Howard Lovatt via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Proposal link: https://github.com/apple/swift-evolution/blob/master/p
>>> roposals/0193-cross-module-inlining-and-specialization.md
>>>
>>>-
>>>
>>>What is your evaluation of the proposal?
>>>
>>>-1
>>>
>>>The proposal puts all the emphasis on the programmer. It is better
>>>for the compiler to decide if something is to be inclined both across
>>>modules and within modules.
>>>
>>>If something is made public then it should be fixed for a given
>>>major version number. No need for extra annotation.
>>>
>>>A module system that allows versioning is a better solution.
>>>-
>>>
>>>Is the problem being addressed significant enough to warrant a
>>>change to Swift?
>>>
>>>Yes significant but wrong solution
>>>-
>>>
>>>Does this proposal fit well with the feel and direction of Swift?
>>>
>>>No, cluttering up declarations is completely against the clarity of
>>>Swift. For example who other than people on this group will understand
>>>@inline(never) @inlinable.
>>>-
>>>
>>>If you have used other languages or libraries with a similar
>>>feature, how do you feel that this proposal compares to those?
>>>
>>>Yes C and C++ and found the equivalent of these annotations
>>>problematic. In Java they eliminated all this and let the compiler do the
>>>work. In practice this works much better.
>>>
>>>Perhaps the compiler should publish the SIL or LLVM for all public
>>>functions. Analogous to Java’s class files. This sort of system works
>>>really will, much better than C and C++.
>>>-
>>>
>>>How much effort did you put into your review? A glance, a quick
>>>reading, or an in-depth study?
>>>Followed the discussions and read 

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Kelvin Ma via swift-evolution]

in theory this could happen but if you ask me this is such an exceedingly
rare case that i don’t count much net benefit from it. most ithing users
(that i know) avoid ios updates like hell but have automatic app updates
turned on. so 99% of the time i would expect the app version to be more
recent than the library version.

On Sun, Dec 24, 2017 at 9:59 PM, Slava Pestov  wrote:

>
>
> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> why can’t we just remove inlineable functions from ABI altogether? if the
> argument is that app code won’t be able to take advantage of improved
> implementations in future library versions i don’t think that makes sense
> at all i would assume client code gets recompiled much more often than
> library code and their updates are much more likely to be downloaded by
> users than library updates.
>
>
> This is not necessarily true. If Swift were to ship with the OS, updating
> the OS might install a new Swift standard library without updating all of
> your apps.
>
> Slava
>
>
> On Sun, Dec 24, 2017 at 6:04 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Proposal link: https://github.com/apple/swift-evolution/blob/master/
>> proposals/0193-cross-module-inlining-and-specialization.md
>>
>>-
>>
>>What is your evaluation of the proposal?
>>
>>-1
>>
>>The proposal puts all the emphasis on the programmer. It is better
>>for the compiler to decide if something is to be inclined both across
>>modules and within modules.
>>
>>If something is made public then it should be fixed for a given major
>>version number. No need for extra annotation.
>>
>>A module system that allows versioning is a better solution.
>>-
>>
>>Is the problem being addressed significant enough to warrant a change
>>to Swift?
>>
>>Yes significant but wrong solution
>>-
>>
>>Does this proposal fit well with the feel and direction of Swift?
>>
>>No, cluttering up declarations is completely against the clarity of
>>Swift. For example who other than people on this group will understand
>>@inline(never) @inlinable.
>>-
>>
>>If you have used other languages or libraries with a similar feature,
>>how do you feel that this proposal compares to those?
>>
>>Yes C and C++ and found the equivalent of these annotations
>>problematic. In Java they eliminated all this and let the compiler do the
>>work. In practice this works much better.
>>
>>Perhaps the compiler should publish the SIL or LLVM for all public
>>functions. Analogous to Java’s class files. This sort of system works
>>really will, much better than C and C++.
>>-
>>
>>How much effort did you put into your review? A glance, a quick
>>reading, or an in-depth study?
>>Followed the discussions and read the proposal. The proposal doesn’t
>>seem to encompass all the discussions. It would be nice if the proposal 
>> had
>>a much more extensive summary of alternatives suggested.
>>
>> -- Howard.
>>
>> On 20 Dec 2017, at 7:19 pm, Ted Kremenek via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> The proposal is available here:
>>
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/0193-cross-module-inlining-and-specialization.md
>>
>> Reviews are an important part of the Swift evolution process. All review
>> feedback 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/proposals/0193-cross-module-inlining-
>> and-specialization.md
>> ...
>> Reply text
>> ...
>> Other replies
>>
>> What goes into a review of a proposal?
>>
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and, eventually, determine the direction of
>> Swift.
>>
>> When reviewing a proposal, here are some questions to consider:
>>
>>-
>>
>>What is your evaluation of the proposal?
>>-
>>
>>Is the problem being addressed significant enough 

Re: [swift-evolution] namespacing protocols to other types

[Kelvin Ma via swift-evolution]

vv

On Sun, Dec 24, 2017 at 11:36 PM, Howard Lovatt 
wrote:

> I would say yes they are different for the example. Definitely something I
> miss is nesting types to given a seperate namespace.
>
> -- Howard.
>
> > On 24 Dec 2017, at 9:56 pm, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > There was a proposal to allow protocols to be nested inside types at one
> point but it didn’t move forward.
> >
> > Basically, if the outer type is a non-generic class, struct or enum,
> there’s no conceptual difficulty at all.
> >
> > If the outer type is a generic type or another protocol, you have a
> problem where the inner protocol can reference generic parameters or
> associated types of the outer type. This would either have to be banned, or
> we would need to come up with coherent semantics for it:
> >
> > struct Generic {
> >  protocol P {
> >func f() -> T
> >  }
> > }
> >
> > struct Conforms : Generic.P {
> >  func f() -> Int { … } // Like this?
> > }
> >
> > let c = Conforms()
> > c is Generic.P // is this false? Ie, are Generic.P and
> Generic.P different protocols?
> >
> > Slava
> >
> >> On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> is there a reason why it’s not allowed to nest a protocol declaration
> inside another type?
> >> ___
> >> 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] namespacing protocols to other types

[Kelvin Ma via swift-evolution]

is there a reason why it’s not allowed to nest a protocol declaration
inside another type?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Kelvin Ma via swift-evolution]

why can’t we just remove inlineable functions from ABI altogether? if the
argument is that app code won’t be able to take advantage of improved
implementations in future library versions i don’t think that makes sense
at all i would assume client code gets recompiled much more often than
library code and their updates are much more likely to be downloaded by
users than library updates.

On Sun, Dec 24, 2017 at 6:04 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal link: https://github.com/apple/swift-evolution/blob/
> master/proposals/0193-cross-module-inlining-and-specialization.md
>
>-
>
>What is your evaluation of the proposal?
>
>-1
>
>The proposal puts all the emphasis on the programmer. It is better for
>the compiler to decide if something is to be inclined both across modules
>and within modules.
>
>If something is made public then it should be fixed for a given major
>version number. No need for extra annotation.
>
>A module system that allows versioning is a better solution.
>-
>
>Is the problem being addressed significant enough to warrant a change
>to Swift?
>
>Yes significant but wrong solution
>-
>
>Does this proposal fit well with the feel and direction of Swift?
>
>No, cluttering up declarations is completely against the clarity of
>Swift. For example who other than people on this group will understand
>@inline(never) @inlinable.
>-
>
>If you have used other languages or libraries with a similar feature,
>how do you feel that this proposal compares to those?
>
>Yes C and C++ and found the equivalent of these annotations
>problematic. In Java they eliminated all this and let the compiler do the
>work. In practice this works much better.
>
>Perhaps the compiler should publish the SIL or LLVM for all public
>functions. Analogous to Java’s class files. This sort of system works
>really will, much better than C and C++.
>-
>
>How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>Followed the discussions and read the proposal. The proposal doesn’t
>seem to encompass all the discussions. It would be nice if the proposal had
>a much more extensive summary of alternatives suggested.
>
> -- Howard.
>
> On 20 Dec 2017, at 7:19 pm, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0193-cross-module-inlining-and-specialization.md
>
> Reviews are an important part of the Swift evolution process. All review
> feedback 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/
> proposals/0193-cross-module-inlining-and-specialization.md
> ...
> Reply text
> ...
> Other replies
>
> What goes into a review of a proposal?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift.
>
> When reviewing a proposal, here are some questions to consider:
>
>-
>
>What is your evaluation of the proposal?
>-
>
>Is the problem being addressed significant enough to warrant a change
>to Swift?
>-
>
>Does this proposal fit well with the feel and direction of Swift?
>-
>
>If you have used other languages or libraries with a similar feature,
>how do you feel that this proposal compares to those?
>-
>
>How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
>
> ___
> 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-0193 - Cross-module inlining and specialization

[Kelvin Ma via swift-evolution]

On Thu, Dec 21, 2017 at 12:26 AM, Slava Pestov  wrote:

> Thanks for the review, Kelvin.
>
> On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> it makes sense to have @abiPublic on private and fileprivate declarations
> too and i hope this gets added, because private and fileprivate are tools
> for code organization and maintenance,, the compiler with wmo doesn’t care
> about private vs internal. but @abiPublic private is bound to cause
> confusion and it just reads funny.
>
>
> From an implementation standpoint, it would be a simple change to allow
> @abiPublic on private and fileprivate declarations. However, I think that
> introduce some confusion. Recall that the mangling of private symbols
> includes the source file name. This would now be part of your framework’s
> ABI. If you moved the @abiPublic function to another source file, or rename
> the source file, you will break ABI.
>
> Another approach would be to change the mangling so that @abiPublic
> private symbols are mangled like internal symbols, with a module name and
> no source file name. This makes for a simpler ABI. However this also has a
> downside, because now if you define two @abiPublic private functions in
> different files that have the same mangling, you will get a linker error
> and not a nice compiler diagnostic.
>
> Note that nothing in this proposal precludes @abiPublic from being applied
> to private and fileprivate symbols though. If we figure out a nice solution
> to the above problems, we could generalize @abiPublic without any issues.
>
> Slava
>
>
i understand that but i also feel like that’s a completely solvable problem
if someone put in some effort to look into it. right now i think
fileprivate is the only problematic keyword with this since i think
changing the name of a private type makes a lot more sense that it would
break abi than renaming a file would. but it’s also the least used so
that’s a plus.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

[Kelvin Ma via swift-evolution]

possibly off-topic but what i would really find useful is some way of
expressing guard/if assignment instead of initialization so that

let geomSource:UnsafeMutableBufferPointer?
if let geometryFile:String = geometryFile
{
guard let _geomSource:UnsafeMutableBufferPointer =
Shader.openTextFile(Shader.posixPath(geometryFile))
else
{
return nil
}

geomSource = _geomSource
}

could be rewritten as

let geomSource:UnsafeMutableBufferPointer?
if let geometryFile:String = geometryFile
{
guard geomSource:UnsafeMutableBufferPointer =
Shader.openTextFile(Shader.posixPath(geometryFile))
else
{
return nil
}
}

On Thu, Dec 21, 2017 at 1:00 PM, Stephen Celis via swift-evolution <
swift-evolution@swift.org> wrote:

> Ah, sorry, I misread! For readability I think I'd still favor something
> like:
>
> if let b = b {
>   dict[a] = b
> }
>
> And I think some the arguments made in #0024 may still apply here, though
> feel free to discuss!
>
> Stephen
>
> On Dec 21, 2017, at 1:37 PM, Benoit Pereira da silva  wrote:
>
> Stephen,
>
> You are right the proposal #0024 is very close.
> But in fact the logic is inverted.
>
> When using «=? » the right item is optional.
> a =? b assigns « b »  to « a »  only if « b »  is defined.
> So if an optional is defined =? will not erase its value.
>
> But my real questions was…
> Do you have such operators that you really use very often?
> Should we incorporate bunches of new operators / micro-syntactic sugar?
> Is swift evolution the good place to discuss such question?
>
> I don’t want to pollute your mail boxes.
>
> Best regards,
>
> B
>
> Le 21 déc. 2017 à 19:12, Stephen Celis  a écrit :
>
> Such an operator was proposed here: https://github.com/
> apple/swift-evolution/blob/60a8980a66a0a1341871ec323797c5
> 547d0e0925/proposals/0024-optional-value-setter.md
>
> It was ultimately rejected: https://lists.swift.
> org/pipermail/swift-evolution-announce/2016-February/43.html
>
> Stephen
>
> On Dec 21, 2017, at 11:44 AM, Benoit Pereira da silva via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Dear all,
>
> That’s not ambitious but i think worth be explored.
>
> What do you think for example of this Infix operator?
> « =? »  allows to express optional assignments  in a very concise way.
>
>
> // The `=? operator allows simplify optional assignements :
> //  `a = b ?? a` can be written : `a =? b`
> infix operator =?: AssignmentPrecedence
>
> public func =? ( left:inout T?, right: T? ){
> left = right ?? left
> }
>
> public func =? ( left:inout T, right: T? ){
> left = right ?? left
> }
>
>
> Do you have such operators that you really use very often?
>
>
> *Benoit Pereira da Silva*
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com
>
> 
>
>
>
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of
> this information for any purpose is prohibited without agreement of the
> sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou
> usage des informations contenues dans ce message sont interdits sans
> agrément préalable de l'expéditeur.
>
>
>
> ___
> 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-0193 - Cross-module inlining and specialization

[Kelvin Ma via swift-evolution]

glad to see this finally moving forward!

On Wed, Dec 20, 2017 at 6:19 PM, Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

> The review of "SE-0193 - Cross-module inlining and specialization" begins
> now and runs through *January 5, 2018*.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0193-cross-module-inlining-and-specialization.md
>
> Reviews are an important part of the Swift evolution process. All review
> feedback 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/
> proposals/0193-cross-module-inlining-and-specialization.md
> ...
> Reply text
> ...
> Other replies
>
> What goes into a review of a proposal?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift.
>
> When reviewing a proposal, here are some questions to consider:
>
>-
>
>What is your evaluation of the proposal?
>
> this is a feature i have been waiting for for a long time so needless to
say i strongly support this proposal. one comment is that @abiPublic is a
kind of awkward thing to have around, not because of how it’s spelled but
because i think access control and abi visibility are orthogonal concepts
and i’m not a fan of overloading access control terms for abi concepts. it
makes sense to have @abiPublic on private and fileprivate declarations too
and i hope this gets added, because private and fileprivate are tools for
code organization and maintenance,, the compiler with wmo doesn’t care
about private vs internal. but @abiPublic private is bound to cause
confusion and it just reads funny.


>
>-
>-
>
>Is the problem being addressed significant enough to warrant a change
>to Swift?
>
> Yes. this issue (along with generic specialization which is really
rendered mostly irrelevant by inlining) is the main technical barrier
preventing a swift core library ecosystem from taking root. formalizing
this feature will allow library authors like me to ship and use modules for
low level tasks, whereas previously the workaround was to copy and paste handy
.swift files  containing
implementations of common data structures and algorithms. ultimately this
will help maintainability, code reuse, and general code base cleanliness.


>
>-
>-
>
>Does this proposal fit well with the feel and direction of Swift?
>
> i don’t see why it wouldn’t. the proposal seems overly conservative and
leans a bit too far towards maximum resilience vs maximum optimization but
that’s fine.

>
>-
>-
>
>If you have used other languages or libraries with a similar feature,
>how do you feel that this proposal compares to those?
>
> this is a big step up from the c++ thing where you would just distribute
giant “header-only” libraries so

>
>-
>-
>
>How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> i read the whole thing,, and i’ve been following this discussion for a
while

>
>-
>
> Thanks,
> Ted Kremenek
> Review Manager
>
>
> ___
> 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 and Timeline for Discourse Transition

[Kelvin Ma via swift-evolution]

On Tue, Dec 12, 2017 at 5:31 AM, Alejandro Martinez via swift-evolution <
swift-evolution@swift.org> wrote:

> This sounds great!
> Specially the new structure, it reminds me of the Rust forums. I just
> have one question, is the Using Swift category expected to be the one
> where the community posts project announcements for new libraries or
> similar stuff? I remember a recent thread where some people wanted to
> include more libs in the standard swift distribution and one of the
> alternatives considered was making it easy for the community to get
> together and share new projects and even join forces. This would seem
> like the perfect place for it, similar to the announcements category
> on Rust forum.
>

i always thought Using Swift was going to be more for beginner questions
and helping newcomers
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] constant var

[Kelvin Ma via swift-evolution]

here’s the problem. if your type is an inline type (ie a struct or an enum),
modifying a member of your object is really modifying part of the entire
variable. so, declaring the variable as let makes no sense. if your type is
an indirect type (a class), modifying a member of your object is really
modifying something that lives in the pointee of the variable. since the
variable itself is really a pointer, declaring it as let makes sense. you
can imagine class members as being accessed like -> in C, except by design
Swift does not need this operator so you can just use the dot to mutate
indirect members. personally i would just use a struct and declare the
variable as mutable as the costs of switching to a class type outweigh the
benefits if you ask me.

On Tue, Dec 12, 2017 at 2:00 AM, Inder Kumar Rathore . via swift-evolution <
swift-evolution@swift.org> wrote:

> Nice idea but I think the code will look ugly
>
> On Tue, Dec 12, 2017 at 1:28 PM, Rafael Guerreiro  > wrote:
>
>> You actually need a class to wrap the dictionary.
>> That’s because dictionaries are struct, with copy-on-write.
>>
>> With a class, you’ll be able to have it mutable, in a let declaration.
>> On Mon, Dec 11, 2017 at 11:34 PM Inder Kumar Rathore . via
>> swift-evolution  wrote:
>>
>>> Hi All,
>>> Today I was writing code and faced a situation where I need to make a
>>> instance variable a const i.e. it shouldn't accept new values from anywhere
>>> but the problem is that I want it's content to be mutable.
>>>
>>> e.g.
>>>
>>> class MyClass {
>>>   var myDict = [String : String]()
>>> }
>>>
>>>
>>> I want above variable to be constant and if I make it like below
>>>
>>> class MyClass {
>>>   let myDict = [String : String]()
>>> }
>>>
>>> Then I cann't add key/value in the myDict like
>>>
>>>self.myDict["name"] = "Rathore"
>>>
>>>
>>> I know swift and couldn't find anything related to this.
>>>
>>> Can anybody help me?
>>>
>>>
>>> If there is no such method of doing it then I would suggest to either
>>> use a syntax like
>>>
>>> class MyClass {
>>>   const var myDict = [String : String]()
>>> }
>>>
>>> I'm not using *final *here since that make a var not overridable.
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Inder Kumar Rathore
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>
>
> --
> Best regards,
> Inder Kumar Rathore
>
> ___
> 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] Optional Argument Chaining

[Kelvin Ma via swift-evolution]

i’ve run into this problem enough to wish this was a thing in Swift a lot,
but when it comes to solutions, i think the proposed syntax just isn’t
clear or easy to read, especially if there’s multiple layers involved.

On Mon, Dec 11, 2017 at 1:28 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> This topic has been discussed at least two and maybe more times in the
> past. It’s hard for me to post links at the moment, but it should be
> possible to find on Google.
>
> One major challenge to this idea, for which no satisfactory answer has
> been achieved after all these years, is the following issue:
>
> f(g()?, h()?, i(), j()?)?
>
> If g() evaluates to nil, is h() called or not? How about i(), which is not
> failable? Since any function or property access can have side effects, in
> what order are the arguments evaluated, and how does one reason about this
> code flow?
>
> To my mind, in the absence of an intuitive answer to the above—which does
> not appear to be possible—this idea is not feasible.
>
> On Mon, Dec 11, 2017 at 12:34 Magnus Ahltorp via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > 12 Dec. 2017 02:58 Jared Khan  wrote:
>> >
>> > 2. It felt natural to me. It’s analogous to the existing optional
>> chaining scenarios and composes nicely. I think it’s about as
>> understandable as existing chaining, a newbie would have to look it up to
>> discover its meaning. What are your thoughts on this particular syntax
>> (ignoring 3. momentarily)? Hopefully others in this thread can share their
>> views too.
>>
>> Chaining methods is linear, while nesting fills a similar purpose when we
>> use function calls. This of course affects the way existing Swift code is
>> written, but that is something we have to live with if we want to use
>> familiar syntax patterns. However, I think we have to consider this
>> difference in this case, since the syntax becomes more convoluted. Your
>> suggestion is definitely not as easy to read as the optional chaining
>> syntax, and maybe it can't be.
>>
>> > As for how common I’d expect it to be, it’s something I’ve run into
>> myself a few times. Again, I hope members of this list can give their view
>> on if this would be useful to them.
>>
>> I don't have any real examples, but I certainly think that I have run
>> into it, so I'm quite open to solving the problem. For me, it is probably
>> only a matter of finding a syntax that is acceptable.
>>
>> > 3. I’m not entirely sure what the grammar situation is yet but afaik
>> ‘?’ has never been available as a postfix operator. Perhaps I’m missing
>> your point, could you demonstrate where it is allowed?
>>
>> I did not expect that you would be able to answer that, it was more a
>> question directed to people who are more connected to the inner workings of
>> the parsing of Swift than I am. It is not allowed, but the error message is
>> not the one I expect, something that gives me a hint that it does have some
>> meaning early in the parsing.
>>
>> /Magnus
>>
>> ___
>> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> > On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
> >
> > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
> >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >>>
> >>>
> >>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >>>>
> >>>> when SE-185 <https://github.com/apple/swift-evolution/blob/master/
> proposals/0185-synthesize-equatable-hashable.md> went through swift
> evolution, it was agreed that the next logical step <
> https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html> is
> synthesizing these conformances for tuple types, though it was left out of
> the original proposal to avoid mission creep. I think now is the time to
> start thinking about this. i’m also tacking on Comparable to the other two
> protocols because there is precedent in the language from SE-15 <
> https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-
> comparison-operators.md> that tuple comparison is something that makes
> sense to write.
> >>>>
> >>>> EHC conformance is even more important for tuples than it is for
> structs because tuples effectively have no workaround whereas in structs,
> you could just manually implement the conformance.
> >>>
> >>> In my opinion, you’re approaching this from the wrong direction.  The
> fundamental problem here is that tuples can’t conform to a protocol.  If
> they could, synthesizing these conformances would be straight-forward.
> >> It would be a tractable intermediate problem to introduce built-in
> conformances for tuples (and perhaps metatypes) to
> Equatable/Hashable/Comparable without breaching the more general topic of
> allowing these types to have general protocol conformances. I think that
> would cover the highest-value use cases.
> >
> > So, shouldn't we do this first step ASAP and then design a good common
> solution to allow tuples/metatypes/funcs to confirm to custom protocols in
> some next version of Swift?
> > I really believe this is the good practical decision and will be
> supported by community if such proposal will be on the table.
> > Is there any drawback in such step?
>
> The expected behavior of tuple Equatable/Hashable/Comparable seems obvious
> to me (though I could well be missing something), and any behavior we
> hardcode should be naturally replaceable by a generalized conformance
> mechanism, so it's primarily a "small matter of implementation". There
> would be some implementation cost to managing the special case in the
> compiler and runtime; the tradeoff seems worth it to me in this case, but
> others might reasonably disagree. Not speaking for the entire core team, I
> would personally support considering a proposal and implementation for
> builtin tuple Equatable/Hashable/Comparable conformance.
>
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

i wouldn’t know how to implement this but i could write up this proposal in
a few days
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Tue, Nov 28, 2017 at 3:18 AM, Xiaodi Wu  wrote:

>
> On Tue, Nov 28, 2017 at 00:32 Kelvin Ma  wrote:
>
>> On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu  wrote:
>>
>>> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma  wrote:
>>>


 On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu  wrote:

> On Mon, Nov 27, 2017 at 15:46 Taylor Swift 
> wrote:
>
>> they use packed buffers of floats, which for type safety are better
>> rebound to a structured type. right now (Float, Float, Float) works 
>> because
>> the tuple is laid out contiguously and the GPU can’t tell the difference
>> but it’s not guaranteed. also you’re ignoring all the CPU stages that 
>> occur
>> before anything even gets sent to the GPU.
>>
>
> Precisely, there is no guarantee of performance if you call these APIs
> with an array of Swift tuples.
>

 which is exactly why i support a dedicated language-level vector type
 which guarantees contiguous, fixed storage, and which the compiler knows
 about so it can vectorize operations on them.

>>>
>>> That's an entirely separate discussion.
>>>
>>>
 tuples right now try to fill too many roles and that makes life
 difficult for both the compiler and the programmer. however, until then, we
 need some kind of common, fixed layout currency type for vector data, and
 by implementation-detail, *tuples are our best option* since for some
 reason everyone is so opposed to the simple solution of baking vec2,
 vec3, … vec5 into the language and the generic integer Vector
 solution everyone wants likely isn’t going to materialize for the
 foreseeable future.

>>>
>>> Disagree. If you want a particular memory layout, define your type in C.
>>> Swift's interop story is very good, and your type will have a fixed layout
>>> forever.
>>>
>>
>> “*write it in c and import it*” is *not* a solution,, it is a workaround.
>>
>
> Yes, that’s what we’re talking about here: workarounds to lack of a fixed
> layout type. I’m saying C is the “best option” workaround, not tuples.
>
> plus since it lives across the module boundary, it’s effectively opaque to
>> compiler optimizations.
>>
> What sorts of optimizations are you referring to? Recall that we are
> talking about taking a value and unsafe bitcasting for the purposes of
> calling other C APIs.
>
> you misunderstand the use-case. C and C APIs usually don’t show up in the
story until the very last step, when you send the buffer to the drawing
library (cairo, opengl, etc). all the stages that come before are swift and
involve passing data between two swift interfaces.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu  wrote:

> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma  wrote:
>
>>
>>
>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu  wrote:
>>
>>> On Mon, Nov 27, 2017 at 15:46 Taylor Swift  wrote:
>>>
 they use packed buffers of floats, which for type safety are better
 rebound to a structured type. right now (Float, Float, Float) works because
 the tuple is laid out contiguously and the GPU can’t tell the difference
 but it’s not guaranteed. also you’re ignoring all the CPU stages that occur
 before anything even gets sent to the GPU.

>>>
>>> Precisely, there is no guarantee of performance if you call these APIs
>>> with an array of Swift tuples.
>>>
>>
>> which is exactly why i support a dedicated language-level vector type
>> which guarantees contiguous, fixed storage, and which the compiler knows
>> about so it can vectorize operations on them.
>>
>
> That's an entirely separate discussion.
>
>
>> tuples right now try to fill too many roles and that makes life difficult
>> for both the compiler and the programmer. however, until then, we need some
>> kind of common, fixed layout currency type for vector data, and by
>> implementation-detail, *tuples are our best option* since for some
>> reason everyone is so opposed to the simple solution of baking vec2, vec3,
>> … vec5 into the language and the generic integer Vector
>> solution everyone wants likely isn’t going to materialize for the
>> foreseeable future.
>>
>
> Disagree. If you want a particular memory layout, define your type in C.
> Swift's interop story is very good, and your type will have a fixed layout
> forever.
>

“*write it in c and import it*” is *not* a solution,, it is a workaround.
plus since it lives across the module boundary, it’s effectively opaque to
compiler optimizations.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Thu, Nov 23, 2017 at 7:08 PM, Xiaodi Wu  wrote:

>
> On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote:
>>
>>>
>>> a good idea on paper, a disastrous one in practice. What happens if
>>> every geometry library declares their own Point type?
>>>
>>> That would be ugly („disastrous“ imho is a little bit to strong — C++
>>> had/has similar issues, and other languages as well)
>>> But if there would be a simple Point struct in a library that is popular
>>> (could be achieved by shipping it alongside the stdlib), this problem would
>>> be solved (there has been a pitch lately, but I guess it faded away
>>> silently).
>>>
>>
>> it’s ugly in C++ and disastrous in Swift because C++ has fixed layout
>> guarantees and everyone agrees that z comes after y comes after x, so you
>> can unsafe-bitcast the foreign C++ points into your own points “for free”.
>> you can’t do the same thing in Swift
>>
>
> Why do you need to have this ability to unsafe bitcast? Is interconversion
> between point types such a common operation that it's a performance
> bottleneck?
>

idk if it’s a performance bottleneck because i use tuples in my geometry
stack and i keep the bottom 2 levels in the same module but it cannot be
good. a lot of the geometry code I write sits atop 2 or 3 other layers of
geometry code beneath it, and it interops with geometry APIs in other
libraries. for example it might be organized like

[ Client geometry code ] ←→ [ Library geometry code ] (example:
Voronoi.voronoi(_:), Noise.perlin(_:_:))
   [ Procedurally generated geometry ] (example:
makeSphere(resolution:))
   [Matrices and projections ] (example:
Geometry.clockwise(_:_:center:normal:))
   [   Math  ] (example: Math.cross(_:_:))

converting at every boundary seems like something to avoid. not to mention
the sheer amount of boilerplate all those conversions produce.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Raw mode string literals

[Kelvin Ma via swift-evolution]

aren’t all literals evaluated at compile time?

On Thu, Nov 23, 2017 at 6:07 PM, Tony Allevato 
wrote:

> This could be solved by extending the existing string literal handling and
> letting type inference do the rest. The real problem here is that
> `UInt8(ascii: X)` is annoying to write when you're dealing with a large
> amount of low-level data.
>
> If UInt8 conformed to ExpressibleByUnicodeScalarLiteral, you could get
> most of the way there—you'd just have to have it fail at runtime for
> anything outside 0...127. But then you could write `let c: UInt8 = "x"` and
> it would just work.
>
> Failing at runtime is undesirable though, so you could take it further and
> add an ExpressibleByASCIILiteral protocol which would be known to the
> compiler, and it would emit an error at compile time if the literal wasn't
> a single ASCII character (like it does today for Character).
>
> One of the things I think is really elegant about Swift is that string
> literals are untyped by themselves and take on an appropriate type based on
> the context they're used in. Handling different kinds of strings should
> leverage and extend that mechanism, not add new syntax.
>
>
> On Thu, Nov 23, 2017 at 2:43 PM Kelvin Ma  wrote:
>
>> On Thu, Nov 23, 2017 at 3:47 PM, Tony Allevato via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>>
>>>
>>> On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution <
 swift-evolution@swift.org> wrote:

> I’m beginning to wish I hadn’t tied this proposal so strongly to
> regular expressions!
> It is indeed the wrong motivation. Even as a ten year veteran of Perl
> development
> I’m not sure we want to bake it into the language quite so tightly
> (isn’t a part of
> Foundation?) What would /regex/ represent - an instance of
> NSRegularExpression?
> Would the flags be pattern options or matching options? This is a
> whole other debate.
>
> For me the focus of raw strings was a sort of super-literal literal
> which has many
> applications. The r”literal” syntax has a precedent in Python and
> there seemed
> to be a syntactic gap that could be occupied but perhaps there are
> other alternatives
> we could discuss. It would be a shame to see ‘quoted strings’ be used
> for this however.
> I still live in hope one day it will be used for single character
> UNICODE values.
>
> Since what passes for a single character changes by Unicode
 revision--such as whenever they get around to enumerating the permitted
 modifying attributes of the poop emoji--it is quite impossible (and Swift's
 `Character` doesn't attempt to) to enforce single-characterness at compile
 time. We should put any such notions to rest up front.

>>>
>>> Unless I'm misunderstanding you here, I don't think that's true: writing
>>> something like `let c: Character = "ab"` is definitely a compile-time
>>> error: https://gist.github.com/allevato/ae267e27939d6233d66a87b48fc0
>>>
>>> To the original point though, I don't think Swift needs to use single
>>> quotes for single characters (or single scalars). Type inference already
>>> infers Characters from single-character String literals in contexts where a
>>> Character is expected, and the only time you need to be explicit is if
>>> you're trying to resolve an overload or initialize a variable by itself.
>>> Using single quotes to avoid writing "as Character" would feel like a waste.
>>>
>>
>> i still think single quotes should be used as an alternate literal for
>> UInt8, like char. there’s a lot of cases where you’re working with
>> low-level 8-bit ASCII data and both String and Character and Unicode.Scalar
>> are inappropriate, and typing out hex literals makes code *less* readable.
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Thu, Nov 23, 2017 at 5:45 PM, Kelvin Ma  wrote:

>
>
> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote:
>
>>
>> a good idea on paper, a disastrous one in practice. What happens if every
>> geometry library declares their own Point type?
>>
>> That would be ugly („disastrous“ imho is a little bit to strong — C++
>> had/has similar issues, and other languages as well)
>> But if there would be a simple Point struct in a library that is popular
>> (could be achieved by shipping it alongside the stdlib), this problem would
>> be solved (there has been a pitch lately, but I guess it faded away
>> silently).
>>
>
> it’s ugly in C++ and disastrous in Swift because C++ has fixed layout
> guarantees and everyone agrees that z comes after y comes after x, so you
> can unsafe-bitcast the foreign C++ points into your own points “for free”.
> you can’t do the same thing in Swift
>

ps i remember that pitch because i’m pretty sure i was the one that pitched
that. consensus seemed it was too high level for inclusion (even though
having it at the stdlib level would do wonders for things like SIMD) and
everyone got distracted by “integers as generic parameters” (because we
love `Vector<3>` ig) because everything on this list always devolves into
“but this is *really* a problem with the *generics system*” and since no
one knows how to fix the generics system everyone calls it a day and
forgets about the original issue
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote:

>
> a good idea on paper, a disastrous one in practice. What happens if every
> geometry library declares their own Point type?
>
> That would be ugly („disastrous“ imho is a little bit to strong — C++
> had/has similar issues, and other languages as well)
> But if there would be a simple Point struct in a library that is popular
> (could be achieved by shipping it alongside the stdlib), this problem would
> be solved (there has been a pitch lately, but I guess it faded away
> silently).
>

it’s ugly in C++ and disastrous in Swift because C++ has fixed layout
guarantees and everyone agrees that z comes after y comes after x, so you
can unsafe-bitcast the foreign C++ points into your own points “for free”.
you can’t do the same thing in Swift
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Raw mode string literals

[Kelvin Ma via swift-evolution]

On Thu, Nov 23, 2017 at 3:47 PM, Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Thu, Nov 23, 2017 at 12:21 PM Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Thu, Nov 23, 2017 at 2:14 PM, John Holdsworth via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I’m beginning to wish I hadn’t tied this proposal so strongly to regular
>>> expressions!
>>> It is indeed the wrong motivation. Even as a ten year veteran of Perl
>>> development
>>> I’m not sure we want to bake it into the language quite so tightly
>>> (isn’t a part of
>>> Foundation?) What would /regex/ represent - an instance of
>>> NSRegularExpression?
>>> Would the flags be pattern options or matching options? This is a whole
>>> other debate.
>>>
>>> For me the focus of raw strings was a sort of super-literal literal
>>> which has many
>>> applications. The r”literal” syntax has a precedent in Python and there
>>> seemed
>>> to be a syntactic gap that could be occupied but perhaps there are other
>>> alternatives
>>> we could discuss. It would be a shame to see ‘quoted strings’ be used
>>> for this however.
>>> I still live in hope one day it will be used for single character
>>> UNICODE values.
>>>
>>> Since what passes for a single character changes by Unicode
>> revision--such as whenever they get around to enumerating the permitted
>> modifying attributes of the poop emoji--it is quite impossible (and Swift's
>> `Character` doesn't attempt to) to enforce single-characterness at compile
>> time. We should put any such notions to rest up front.
>>
>
> Unless I'm misunderstanding you here, I don't think that's true: writing
> something like `let c: Character = "ab"` is definitely a compile-time
> error: https://gist.github.com/allevato/ae267e27939d6233d66a87b48fc0
>
> To the original point though, I don't think Swift needs to use single
> quotes for single characters (or single scalars). Type inference already
> infers Characters from single-character String literals in contexts where a
> Character is expected, and the only time you need to be explicit is if
> you're trying to resolve an overload or initialize a variable by itself.
> Using single quotes to avoid writing "as Character" would feel like a waste.
>

i still think single quotes should be used as an alternate literal for
UInt8, like char. there’s a lot of cases where you’re working with
low-level 8-bit ASCII data and both String and Character and Unicode.Scalar
are inappropriate, and typing out hex literals makes code *less* readable.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

a good idea on paper, a disastrous one in practice. What happens if every
geometry library declares their own Point type?

On Tue, Nov 21, 2017 at 1:15 AM, Thorsten Seitz  wrote:

>
>
> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution <
> swift-evolution@swift.org>:
>
> when SE-185
> <https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md>
> went through swift evolution, it was agreed that the next logical step
> <https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html> is
> synthesizing these conformances for tuple types, though it was left out of
> the original proposal to avoid mission creep. I think now is the time to
> start thinking about this. i’m also tacking on Comparable to the other
> two protocols because there is precedent in the language from SE-15
> <https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
> that tuple comparison is something that makes sense to write.
>
> EHC conformance is even more important for tuples than it is for structs
> because tuples effectively have no workaround whereas in structs, you could
> just manually implement the conformance. this is especially relevant in
> graphics and scientific contexts where tuples are used to represent color
> values and points in 2D or 3D space. today you still can’t do things like
>
> let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .
>
> the commonly suggested “workaround”, which is to “upgrade” the tuple to a
> struct is problematic for two reasons:
>
> 1. it defeats the purpose of having tuples in the language
>
> 2. tuples are a logical currency type for commonly used types like points
> and vectors. If every library defined its own custom point/vector types we
> would soon (already?) have a nightmare situation where no geometry/graphics
> library would be compatible with any other geometry/graphics library, at
> least not without a lot of annoying, let alone wasteful swizzling and
> manual conversion routines in the main application.
>
>
> Actually I don't think that tuples should be used for points and vectors
> at all, because I prefer to differentiate these two concepts which requires
> nominal types, e.g.
>
> struct Point {
> func distance(to point: Point) -> Vector
> func offsetBy(_ offset: Vector) -> Point
> }
>
> Notwithstanding this disagreement I too think that EHC conformance for
> tuples would be useful.
>
> -Thorsten
>
>
> ___
> 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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

can we go the route of SE-15 and just synthesize up to some sensible n = 7
or whatever. i feel like this list has a habit of going “but it would be a
lot better to add X if we just wait until Y is a thing first” ignoring that
Y will probably not be a thing for the forseeable future and we really need
X right now

On Mon, Nov 20, 2017 at 9:10 PM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Ignoring synthesized conformances for a second, think about how you would
> manually implement a conformance of a tuple type to a protocol. You would
> need some way to statically “iterate” over all the component types of the
> tuple — in fact this is the same as having variadic generics.
>
> If we had variadic generics, we could implement tuples conforming to
> protocols, either by refactoring the compiler to allow conforming types to
> be non-nominal, or by reworking things so that a tuple is a nominal type
> with a single variadic generic parameter.
>
> Slava
>
>
> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is something I've wanted to look at for a while. A few weeks ago I
> pushed out https://github.com/apple/swift/pull/12598 to extend the
> existing synthesis to handle structs/enums when a field/payload has a tuple
> of things that are Equatable/Hashable, and in that PR it was (rightly)
> observed, as Chris just did, that making tuples conform to protocols would
> be a more general solution that solves the same problem you want to solve
> here.
>
> I'd love to dig into this more, but last time I experimented with it I got
> stuck on places where the protocol conformance machinery expects
> NominalTypeDecls, and I wasn't sure where the right place to hoist that
> logic up to was (since tuples don't have a corresponding Decl from what I
> can tell). Any pointers?
>
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Nov 20, 2017, at 5:48 PM, Kelvin Ma  wrote:
>>
>> the end goal here is to use tuples as a compatible currency type, to that
>> end it makes sense for these three protocols to be handled as “compiler
>> magic” and to disallow users from manually defining tuple conformances
>> themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
>> Comparable are special because they’re the basis for a lot of standard
>> library functionality so i think the benefits of making this a special
>> supported case outweigh the additional language opacity.
>>
>>
>> I understand your goal, but that compiler magic can’t exist until there
>> is something to hook it into.  Tuples can’t conform to protocols right now,
>> so there is nothing that can be synthesized.
>>
>> -Chris
>>
>>
>>
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner 
>> wrote:
>>
>>>
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> when SE-185
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md>
>>> went through swift evolution, it was agreed that the next logical step
>>> <https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html>
>>> is synthesizing these conformances for tuple types, though it was left out
>>> of the original proposal to avoid mission creep. I think now is the time to
>>> start thinking about this. i’m also tacking on Comparable to the other
>>> two protocols because there is precedent in the language from SE-15
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
>>> that tuple comparison is something that makes sense to write.
>>>
>>> EHC conformance is even more important for tuples than it is for structs
>>> because tuples effectively have no workaround whereas in structs, you could
>>> just manually implement the conformance.
>>>
>>>
>>> In my opinion, you’re approaching this from the wrong direction.  The
>>> fundamental problem here is that tuples can’t conform to a protocol.  If
>>> they could, synthesizing these conformances would be straight-forward.
>>>
>>> If you’re interested in pushing this forward, the discussion is “how do
>>> non-nominal types like tuples and functions conform to protocols”?
>>>
>>> -Chris
>>>
>>>
>>>
>>>
>>>
>> ___
>> swift-ev

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

the end goal here is to use tuples as a compatible currency type, to that
end it makes sense for these three protocols to be handled as “compiler
magic” and to disallow users from manually defining tuple conformances
themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and
Comparable are special because they’re the basis for a lot of standard
library functionality so i think the benefits of making this a special
supported case outweigh the additional language opacity.

On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  wrote:

>
> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> when SE-185
> <https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md>
> went through swift evolution, it was agreed that the next logical step
> <https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html> is
> synthesizing these conformances for tuple types, though it was left out of
> the original proposal to avoid mission creep. I think now is the time to
> start thinking about this. i’m also tacking on Comparable to the other
> two protocols because there is precedent in the language from SE-15
> <https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
> that tuple comparison is something that makes sense to write.
>
> EHC conformance is even more important for tuples than it is for structs
> because tuples effectively have no workaround whereas in structs, you could
> just manually implement the conformance.
>
>
> In my opinion, you’re approaching this from the wrong direction.  The
> fundamental problem here is that tuples can’t conform to a protocol.  If
> they could, synthesizing these conformances would be straight-forward.
>
> If you’re interested in pushing this forward, the discussion is “how do
> non-nominal types like tuples and functions conform to protocols”?
>
> -Chris
>
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Kelvin Ma via swift-evolution]

when SE-185

went through swift evolution, it was agreed that the next logical step
 is
synthesizing these conformances for tuple types, though it was left out of
the original proposal to avoid mission creep. I think now is the time to
start thinking about this. i’m also tacking on Comparable to the other two
protocols because there is precedent in the language from SE-15

that tuple comparison is something that makes sense to write.

EHC conformance is even more important for tuples than it is for structs
because tuples effectively have no workaround whereas in structs, you could
just manually implement the conformance. this is especially relevant in
graphics and scientific contexts where tuples are used to represent color
values and points in 2D or 3D space. today you still can’t do things like

let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .

the commonly suggested “workaround”, which is to “upgrade” the tuple to a
struct is problematic for two reasons:

1. it defeats the purpose of having tuples in the language

2. tuples are a logical currency type for commonly used types like points
and vectors. If every library defined its own custom point/vector types we
would soon (already?) have a nightmare situation where no geometry/graphics
library would be compatible with any other geometry/graphics library, at
least not without a lot of annoying, let alone wasteful swizzling and
manual conversion routines in the main application.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-dev] Forums for swift.org workgroup: looking for volunteers

[Kelvin Ma via swift-evolution]

im willing to help!

On Wed, Nov 15, 2017 at 6:01 PM, Wallacy via swift-evolution <
swift-evolution@swift.org> wrote:

> I will be on vacation after December 1, so I will have some time to help
> if needed.
> Em qua, 15 de nov de 2017 às 21:39, Nicole Jacque via swift-dev <
> swift-...@swift.org> escreveu:
>
>> As Ted Kremenek has previously announced, we are in the process of moving
>> the Swift mailing lists to Discourse. Previously the discussion was mostly
>> about moving swift-evolution over to a forum, but the consensus from Ted
>> and the Core Team was that should look to move all the lists to Discourse
>> for consistency.
>>
>> I will be shepherding the transition from the mailing lists to the forum.
>> Rather than simply move the existing lists and structure as-is, we’d like
>> to take this opportunity to explore new ways of organizing the forums to
>> help foster communication and collaboration. We also have a number of new
>> options that will be available with Discourse, that we’d like some input
>> from the community on.
>>
>> To help with this, I am looking for 3-4 volunteers from the Swift
>> community to create a workgroup to discuss and create a plan for the
>> structure for the Discourse-based forums. We will then present this plan
>> back to the community. We are also investigating the possibility of having
>> a preview version of the forums available for comment from the community.
>>
>> If you would like to be part of this workgroup, please reply back to me
>> and let me know!
>>
>> Thanks!
>> Nicole
>> ___
>> swift-dev mailing list
>> swift-...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>
> ___
> 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] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

Glad to see people working on this! I already have a functioning
almost-pure Swift PNG library , and a JPEG
library  is a month or two away. I’m glad
someone is hacking away at some sort of rasterization engine (like cairo
for C/C++). The way I see a lot of these graphics libraries is they live in
a sort of “tech tree” and a lot of them depend on support higher up the
tree, like in a video game. For now we seem to be filling in a lot of the
top row with C libraries which doesn’t always work too well (like in the
case of zlib).

   Rasterizer  File I/O, path manipulation ——+——— LZ77
compression
[{cairo equiv.}][{file manager lib}, URL
]| [{zlib equiv.}]
|  | |
| +—+——+++——+
| | |  |||  |
|XML  HTML  TTF/OTF   JPEG  PNG   GZIP
|[swiftxml ]  [{???}]
[{???}]  [JPEG ]   [MaxPNG
]  [{archiving lib}]
|| ||
+|———+—+———++
+——+—+   | |
   | | |
  SVG  Text renderer  WOFF
[{???}] [{freetype equiv.}]  [{???}]

On Thu, Nov 9, 2017 at 9:25 AM, Benjamin Spratling via swift-evolution <
swift-evolution@swift.org> wrote:

> Sound great!
>
> Last week I started working on a pure-swift graphics library, one goal
> being fast server-side graphics manipulations, and already have .png
> decode/encode, and quadratic bezier curve stroking implemented, slowly, and
> poorly.  I’m working on TrueType fonts right now, and intend to open it to
> other developers once the basic architecture is refined.  I intend to add
> SVG and JPEG support as well.  It seems like if there is a “swift-community
> blessed geometry library”, this would be a natural extension of that, or at
> least depend on it.
>
> Much of this depends on compression support, which I’ve already published
> a first cut of at https://github.com/benspratling4/
> SwiftFoundationCompression .  The goal there was a more “foundation” idea
> of compression than competing libraries, but it suffers from a lack of
> streaming support.
>
> I would absolutely love a “BigNum” library.  Several encryption packages
> out there would benefit from it as well.  It seems arithmetic compression
> libraries would benefit, too.  Other useful Numeric types would include
> rational fractions, fixed-point, and short floats (Float16 is what Apple
> now thinks the future of images is, right?).  I’m happy to contribute; I
> end up writing those in a new language ever few years anyway.
>
> -Ben Spratling
>
>
> On Nov 7, 2017, at 12:54 PM, Dave DeLong via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Swift-Evolution,
> ...
>
> We propose to create an open-sourced "Non-Standard Library" effort that
> coexists with, coordinates with, and is blessed by the open source Swift
> development community. The "Non-Standard Library" will offer a
> well-curated, high-value collection of routines, types, and documentation
> to support Swift development on all platforms.
> …
>
>
> *Suggested Libraries*
>
> There are several areas we think that are ripe for improvement and
> implementation as a non-standard library, such as (but not limited to):
>
>- A BigNum library
>- A full-featured Random library
>- A simplified date/time library
>- A library for manipulating paths (that is not based on URL or String)
>- An expanded Swift-native Geometry library and so forth.
>
> The scope and extent of the sublibraries would be proposed and debated on
> a parallel Non-Standard Library Evolution development list.
>
>
>
> ___
> 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] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Thu, Nov 9, 2017 at 12:37 PM, Wallacy via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Em qui, 9 de nov de 2017 às 03:42, Ted Kremenek 
> escreveu:
>
>> These are some really interesting analogies.  How would you imagine the
>> community “governance” of these “plugins” (which I assume would be
>> libraries or packages) to be managed?
>>
>
> Pretty much like a TV/Games/etc community forums. The owner (In this case
> Apple/Core Team) invite some people to help (Moderators etc) to maintain
> the main project, look if everyone is follow the rules, etc.
>
> Also is similar as other opensource projects.
>
>
>> What does it mean for the “full community” to manage them, and provide
>> the rough guarantees you suggest?
>>
>
> NPM has thousands of projects, is impossible to check all of then. And
> besides be a good reference, here we have the opportunity do to something
> better... Because...Because...Because I believe we can ;)
>
> So what i expect?
>
> Lets make some assumptions here, just to play a little:
>
> Let assume we build a Indexer like IBM Swift Package Catalog (
> https://packagecatalog.com/ ) over Swift.org.
>
> And like Swift Source Compatibility Suite to be "indexed" the author of
> the project needs to send the request to be accepted.
>
> Lets assume the same rules as Compatibility Suite:
> Acceptance Criteria
>
> To be accepted into the Swift source compatibility test suite, a project
> must:
>
>1. Target Linux, macOS, or iOS/tvOS/watchOS device
>2. Be an *Xcode* or *Swift Package Manager* project (Carthage and
>CocoaPods are currently unsupported but are being explored to be supported
>in the future)
>3. Support building on either Linux or macOS
>4. Be contained in a publicly accessible git repository
>5. Maintain a project branch that builds against Swift 3.0
>compatibility mode and passes any unit tests
>6. Have maintainers who will commit to resolve issues in a timely
>manner
>7. Be compatible with the latest GM/Beta versions of *Xcode* and
>*swiftpm*
>8. Add value not already included in the suite
>9. Be licensed with one of the following permissive licenses:
>   - BSD
>   - MIT
>   - Apache License, version 2.0
>   - Eclipse Public License
>   - Mozilla Public License (MPL) 1.1
>   - MPL 2.0
>   - CDDL
>
> i’m okay with this as long as point 9 is changed to accept copyleft
licenses like GPL. currently this is a huge hole in the SSCS which i am
sure will cause issues down the road
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

i’m not one to applaud everything go does but its extended standard library
seems nice

On Thu, Nov 9, 2017 at 2:24 AM, Nick Keets via swift-evolution <
swift-evolution@swift.org> wrote:

> I think there are two ideas discussed in this thread at the same time. One
> is for a more extended standard library, that is developed and shipped as
> part of the language. This is similar to what Python, Go and other
> languages are doing. The second is for a more wide collection of packages,
> developed by 3rd parties and not included with the language. This is
> similar to npm, PyPI, etc.
>
> If I understood it correctly, the original proposal is about the first
> idea and I don't think an "open market" approach works well for this. As
> for what should be included, I find Go to be a nice example, that could be
> used as a starting point:
>
> https://golang.org/pkg/
>
> To summarize, it includes:
> - archival and compression formats (tar, zip, gzip, ...)
>

will be an open problem to port zlib to Swift, but it’s doable


> - a few data structures
>

lots of incomplete implementations floating around GitHub, none really
stand out because i feel like most people have gotten used to rolling their
own since we still don’t have a Swift equivalent of std::priority_queue. at
this point i just have Queue.swift file lying around that I copy and paste
whenever i need it. which is bad.


> - cryptographic functions (including hashes and random numbers)
>

This is being talked about right now, mostly about random number
generation, less on cryptography since it’s really easy to mess that up


> - sqlite and basic database drivers support
> - various data encodings (CSV, XML, JSON, ...)
>

I have an Linux-compatible XML library
 in progress, last I remember the
Foundation class didn’t work on Linux


> - some stuff used internally by the go tools (AST trees, debugging symbols)
> - basic graphics and image support
>

i maintain a Swift PNG codec , and am
developing a pure Swift JPEG codec 


> - basic text and HTML templates
>

could really use these, don’t know of any cross-platform Swift libraries
for these


> - math and bignums
>

peep https://github.com/attaswift/BigInt and
https://github.com/xwu/NumericAnnex


> - networking and HTTP support (client and server)
>

isn’t there a server working group?


> - OS support (including path handling, command line flags etc)
>

YES. currently working on a new URI type 
to replace the Foundation one which is really just a wrapper around NSURL
which is in turn a wrapper around CFURL. which is bad.


> - Miscellanous stuff like dates, unicode, IO, string parsing, testing, etc.
>

yes


> Go considers all these packages part of the language and offers source
> compatibility guarantees for all of them. I find the availability of these
> packages and the fact that they are developed and maintained by the Go core
> team to be very powerful.
>
> We can debate what should be included and if these should be separate
> modules or not, but I think the key insight here is that they are a curated
> list of useful libraries that are developed and maintained together with
> the language.
>
>
> On Wed, Nov 8, 2017 at 9:37 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Nov 8, 2017, at 4:54 AM, Karl Wagner  wrote:
>>
>> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> FWIW, Ben Cohen and I have been talking about possibly using Swift
>> packages as a way to seed out experimental ideas for extensions to the
>> Standard Library.  This would allow ideas to be trialed by real usage (a
>> complaint I’ve seen about some changes we’ve made to Swift in the past).
>> Users could build things on top of those libraries, knowing they are
>> available as packages, and if an API “graduates” to being part of the
>> Standard Library the user can then depend upon it being available there.
>> If it never graduates, however, the package remains around.
>>
>>
>> Yeah this is exactly the problem that the package manager is there to
>> solve, right? It’s supposed to make it ridiculously easy to integrate
>> libraries and manage your dependencies.
>>
>> The problem is that most people writing Swift code every day are doing it
>> to make graphical applications on iOS/macOS. SwiftPM doesn’t support those,
>> so if I want to test a library, it’s just a one-off thing that I play with
>> in a Playground.
>>
>>
>> I think that the best thing we could do to encourage people to write, use
>> and contribute to public libraries would be to improve the package manager.
>> SwiftPM is still basically a toy (or an interesting curiosity), until it
>> can actually be used in the projects most Swift devs get paid to work on
>> every day. Talking about it supporting a community is way premature; it’s
>> no

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Thu, Nov 9, 2017 at 1:49 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Nov 7, 2017, at 5:54 PM, Dave DeLong via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hi Swift-Evolution,
> >
> > The Standard Library's goal is to be small and targeted. However, many
> aspects of Apple-provided frameworks need or offer opportunities for
> improvement or wholesale replacement. These enhancements lie beyond the
> scope of the Standard Library.
> >
> > To address this, we'd like to propose the idea of a "Non-Standard
> Library"; this would be a library that ships with a regular installation of
> Swift, but is not imported into .swift files by the compiler, unless
> explicitly requested by the developer.
> >
> > We are proposing a well-organized effort to parallel the Standard
> Library without putting additional implementation responsibilities onto the
> core team. This effort would mitigate what we see as platform-independent
> requirements that provide native Swift implementations that aren't burdened
> by Apple history.
>
> Hi Dave,
>
> As others have pointed out, we do already have a model for this sort of
> thing: the swift server working group.
>

i feel like the swift server working group is something that is very
difficult to reproduce because in 3 years of Swift it’s the only example of
such a project in existence


>
> That said, there is another analogy which gets closer to what you’re
> asking for: the Boost community for C++.  Boost was formed because the C++
> committee was too bogged down an wasn’t receptive to major library changes
> (at one point in time).  Boost has effectively parallel leadership from the
> C++ committee (though individuals are involved in both organizations of
> course).  This allows Boost to move faster, ship code, and get experience
> with it.
>
> One of the specifically nice things about Boost is that they (at least
> originally) focused on building out ideas, getting experience with them,
> and then bringing the libraries back to the standard.  The libraries
> occasionally undergo significant change when they are standardized, but the
> usage experience is unmatchable, particularly for very large and complex
> APIs.
>
>
the problem is boost doesn’t ship with C++ so people view it as just
another dependency, kind of like jQuery but more annoying because you have
to clone and build this giant support library (at least that was my
experience building Blender back in 2012). the C++ STL library or the
python support modules are probably closer to the distribution model I’d
like to see


> In the context of Swift, I think this sort of model could be very
> interesting, because there are really several different independent things
> going on: for a type like BigNum (for example) there are all the details of
> the implementation and design on the one hand, but then there is also the
> question of WHICH library it should ship with (Foundation or Swift or
> something else).  That second decision is much easier to make after the
> community has converged on a specific design.
>
> In any case, I think it would be a bad move for the official Swift
> distributions to ship code that hasn’t been through the evolution process.
> The idea of the Server working group is to delegate detailed design and
> iteration to a team of experts, but then have them bring back the API to
> evolution when the iteration is done and it is time to “standardize” it.  I
> think that this is a good model.
>
> -Chris
>
> ___
> 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] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Thu, Nov 9, 2017 at 12:11 AM, Ted Kremenek  wrote:

>
>
> On Nov 8, 2017, at 12:08 PM, Kelvin Ma  wrote:
>
>
>
> On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I do not agree with Ted that only a few projects should be ranked,
>> everyone, as it is in npm should be available. Only be graded according to
>> recommendations.
>>
>>
>> I’m a bit confused.  I’m not sure what comments of mine I’m referring to.
>>
>>
>> Clearly I’m double confused.  That meant to read “I’m not sure what
>> comments of mine *you* are referring to”.
>>
>> I fully support having a broad spectrum of libraries that the community
>> builds and uses.  Any library that we decide to make part of “core Swift” —
>> IMHO at a mature point in a library’s evolution — would need to have high
>> value to the majority of the community and would need to feel solid enough
>> that we can lock it in for both source and binary compatibility, high
>> quality of implementation with sustained maintenance, etc.
>>
>
> i mean I don’t think these approaches are incompatible. The “swift core”
> could just make the process of independent libraries getting started
> easier. Like right now there’s really no place to say “hey I just started a
> library project for X, and anyone who wants to be involved should
> contribute at Y github repo where it lives right now”. I’ve tried sending
> that on this list before and it didn’t really work because mailing lists
> aren’t really a good medium for that and no one wants the swift-evolution
> list getting clogged with project-specific messages most people don’t care
> about.
>
>
> These are great points.
>
> FWIW, I’m getting optimistic about moving to a forum soon.  Would you
> expect that a forum could provide a better vehicle than a mailing list to
> arrange communication and interest within the community around building
> libraries?  Not just doing shout outs for projects, but also doing possible
> API design review, etc.?
>

this forum thing has been talked about for almost a year now and i am for
real convinced it will never happen tbh. if it did, it would probably be
more conducive but ultimately it comes down to the number of people
interested because right now it’s like there’s only a handful of people on
this list who want to write open source libraries (or really anything
without a graphical interface since it’s basically 90% ios devs here). will
a forum encourage more people to get involved in the language? maybe, for
me it took a really long time to actually sign up for this mailing list and
talk in it because mailing lists are just not easy to get involved in


>
> As an analogy, within Apple we have various mailing lists to review APIs,
> which is one mechanism used for different teams to co-review newly proposed
> APIs and consider how they compose together with other APIs.  It’s not
> always perfect, but it does help facilitate a culture of API review so that
> various APIs can be considered together and part of the same (or
> compatible) design philosophies.
>
> One of the things that resonated to me from Dave DeLong’s proposal was a
> sense about having a set of libraries that are well-considered and their
> efforts coordinated.  While the coordination pitched in Dave’s proposal was
> about a focused effort on a particular set of libraries/features,
> coordination can also take the form of having a community that cares about
> building good APIs and can constructively discuss them.  This can be done
> while also completely factoring out whether or not those APIs are part of
> “core Swift”.  Further, shared API review wouldn’t necessarily be about
> making actual decisions — which is the case of swift-evolution when
> evaluating language and standard library changes — but offering advice.
> Fundamentally the library author still stays in control of their library
> and APIs, but the community could help in shaping up the gestalt of what
> are considered well-crafted Swift APIs in general.
>
> Of course the big difference here with this idea compared to Apple’s
> internal API review process is that for Apple the APIs it vends are
> intended to be shipped together, and thus they must work together.  In open
> source, however, efforts on various libraries are often (usually?)
> independent.  Projects are usually created independently by different
> authors, and while it may be desirable for APIs from various libraries to
> feel natural to work with together, it’s not a requirement on their
> construction in general.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Wed, Nov 8, 2017 at 1:58 PM, Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Nov 8, 2017, at 11:40 AM, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Nov 8, 2017, at 4:30 AM, Wallacy via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I do not agree with Ted that only a few projects should be ranked,
> everyone, as it is in npm should be available. Only be graded according to
> recommendations.
>
>
> I’m a bit confused.  I’m not sure what comments of mine I’m referring to.
>
>
> Clearly I’m double confused.  That meant to read “I’m not sure what
> comments of mine *you* are referring to”.
>
> I fully support having a broad spectrum of libraries that the community
> builds and uses.  Any library that we decide to make part of “core Swift” —
> IMHO at a mature point in a library’s evolution — would need to have high
> value to the majority of the community and would need to feel solid enough
> that we can lock it in for both source and binary compatibility, high
> quality of implementation with sustained maintenance, etc.
>

i mean I don’t think these approaches are incompatible. The “swift core”
could just make the process of independent libraries getting started
easier. Like right now there’s really no place to say “hey I just started a
library project for X, and anyone who wants to be involved should
contribute at Y github repo where it lives right now”. I’ve tried sending
that on this list before and it didn’t really work because mailing lists
aren’t really a good medium for that and no one wants the swift-evolution
list getting clogged with project-specific messages most people don’t care
about.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Tue, Nov 7, 2017 at 3:15 PM, Félix Fischer  wrote:

> On Tue, Nov 7, 2017 at 5:24 PM Wallacy  wrote:
>
>> The Compatibility Suite is a good start, but I agree that something a
>> bit more centralized has its benefits.
>>
>> To be perfect, Compatibility Suite and Swift Package Manager need to work
>> "together" to offer something simple like nodejs npm and a friendly (and
>> central) interface to not only find these projects. Something more similar
>> to nuget too.
>>
>> The only thing I miss using npm and nuget is some kind of "compromise"
>> with maintenance. And also some commitment to (avoid) rework. Several
>> projects remake something that another does also without explaining well
>> the differences between them.
>>
>> Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in
>> project like Compatibility Suite with steroids. Not only to track those
>> projects, but in some level help defining some standards, documentations,
>> versioning etc. This can be done entirely within the community.
>>
>> Not so similar, however the gstreamer keeps a list of "base", "good",
>> "ugly" and "bad" plugins for similar reasons.
>>
>> We can do something in this line of reasoning:
>> - A central repository for projects (like Compatibility Suite)
>> - A tool to find and add each project (like SwiftPM)
>> - Rules for joining (like Compatibility Suite)
>> - A classification for each repository (like gstreamer)
>> - A good way to make each project as small and direct as possible (to
>> take advantage of cross-module inlining / specialization)
>> - A list of discussion (or a forum?) for people that maintain (or have an
>> interest in maintain) projects in this "official" list.
>>
>
> I like this approach much more. Feels more natural. And a forum
> (piggybacking on the eventual Discourse perhaps). I’d only change two
> things and extend one:
>
> - Instead of “central repository”, a “central index”. It makes it more
> transparent, more distributed, and closer to the current reality.
>
> - Here:
>
>
>> I vote for empowering SwiftPM and Compatibility Suite instead a
>> "Non-Standard Libraries".
>>
>>
> I agree with a central index, but as Kelvin says, we shouldn’t be using
> the Compat Suite directly because of GPL issues.
>
> - I’d extend on the “Rules for Joining” point: they should be as clear and
> explicit as possible, to avoid drama like the one episode that happened
> last year on the JS repositories with that string-padding library. That
> thing broke half of the internet for some hours, and it was all about
> something unclear in the rules, if I remember the case correctly.
>

I think Swift is less vulnerable to that than node.js if anything because
Swift is compiled ahead of time so someone removing their repo doesn’t
instantly break everything else.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

The compatibility suite is not a good model because it was designed for a
completely different purpose. Its license restrictions are so that it can
be shipped in an Apple repository and it’s not really optimized for
discovery or documentation at all. Any non-standard library index must
include GPL licensed libraries, as well as have some common documentation
format. It’d be nice if the index could actually generate documentation
from source comments.

On Tue, Nov 7, 2017 at 2:24 PM, Wallacy  wrote:

> The Compatibility Suite is a good start, but I agree that something a bit
> more centralized has its benefits.
>
> To be perfect, Compatibility Suite and Swift Package Manager need to work
> "together" to offer something simple like nodejs npm and a friendly (and
> central) interface to not only find these projects. Something more similar
> to nuget too.
>
> The only thing I miss using npm and nuget is some kind of "compromise"
> with maintenance. And also some commitment to (avoid) rework. Several
> projects remake something that another does also without explaining well
> the differences between them.
>
> Maybe we don't need to code any "Non-Standard Libraries"! Only a opt-in
> project like Compatibility Suite with steroids. Not only to track those
> projects, but in some level help defining some standards, documentations,
> versioning etc. This can be done entirely within the community.
>
> Not so similar, however the gstreamer keeps a list of "base", "good",
> "ugly" and "bad" plugins for similar reasons.
>
> We can do something in this line of reasoning:
> - A central repository for projects (like Compatibility Suite)
> - A tool to find and add each project (like SwiftPM)
> - Rules for joining (like Compatibility Suite)
> - A classification for each repository (like gstreamer)
> - A good way to make each project as small and direct as possible (to take
> advantage of cross-module inlining / specialization)
> - A list of discussion (or a forum?) for people that maintain (or have an
> interest in maintain) projects in this "official" list.
>
> I vote for empowering SwiftPM and Compatibility Suite instead a
> "Non-Standard Libraries".
>
>
>
> Em ter, 7 de nov de 2017 às 17:19, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> escreveu:
>
>>
>>
>> On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer 
>> wrote:
>>
>>>
>>> On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma  wrote:
>>>
>>>> On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <
>>>> swift-evolution@swift.org> wrote:
>>>>
>>>>> Hmm. I kind of like the idea, but not really. I think it has a
>>>>> fundamental flaw: centralization.
>>>>>
>>>>> You see, the StdLib can be commanded by a central authority (the core
>>>>> team) and hear the needs of the general community (through swift-evolution
>>>>> and such) because, among other things, it’s small. The StdLib solves 
>>>>> common
>>>>> and well-understood problems. Most of the solutions it provides are 
>>>>> optimal
>>>>> for all use cases.
>>>>>
>>>>> This is fundamentally different from a non-StdLib. If I understood
>>>>> your idea correctly, it would be the complement of StdLib; it will be big
>>>>> and it will attend problems that are not well-understood or whose 
>>>>> solutions
>>>>> have many differrying  approaches depending on the users’ neccessities
>>>>> (think Geometry). Therefore, a correct and complete approach would
>>>>> inevitably have to:
>>>>> - Know the needs of all the relevant user groups and balance their
>>>>> priorities.
>>>>> - Contain all the important and complementary solutions.
>>>>>
>>>>> This is very hard to achieve in a centralized system. Not impossible,
>>>>> but very resource-intensive.
>>>>>
>>>>> You can achieve something similar by letting the community grow and by
>>>>> encouraging a good environment. People will the build the tools they need,
>>>>> and the important voices will index the tools people use the most. That
>>>>> makes them good, as well as easily findable. It’s not perfect either, but
>>>>> it’s more efficient in my opinion.
>>>>>
>>>>> — Félix Fischer
>>>>>
>>>>
>>>> People tend to build the tools they need, but

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Tue, Nov 7, 2017 at 1:11 PM, Félix Fischer  wrote:

>
> On Tue, Nov 7, 2017 at 4:01 PM Kelvin Ma  wrote:
>
>> On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Hmm. I kind of like the idea, but not really. I think it has a
>>> fundamental flaw: centralization.
>>>
>>> You see, the StdLib can be commanded by a central authority (the core
>>> team) and hear the needs of the general community (through swift-evolution
>>> and such) because, among other things, it’s small. The StdLib solves common
>>> and well-understood problems. Most of the solutions it provides are optimal
>>> for all use cases.
>>>
>>> This is fundamentally different from a non-StdLib. If I understood your
>>> idea correctly, it would be the complement of StdLib; it will be big and it
>>> will attend problems that are not well-understood or whose solutions have
>>> many differrying  approaches depending on the users’ neccessities (think
>>> Geometry). Therefore, a correct and complete approach would inevitably have
>>> to:
>>> - Know the needs of all the relevant user groups and balance their
>>> priorities.
>>> - Contain all the important and complementary solutions.
>>>
>>> This is very hard to achieve in a centralized system. Not impossible,
>>> but very resource-intensive.
>>>
>>> You can achieve something similar by letting the community grow and by
>>> encouraging a good environment. People will the build the tools they need,
>>> and the important voices will index the tools people use the most. That
>>> makes them good, as well as easily findable. It’s not perfect either, but
>>> it’s more efficient in my opinion.
>>>
>>> — Félix Fischer
>>>
>>
>> People tend to build the tools they need, but not what other people need.
>>
>
> Fair point. Dog-feeding might be an issue, but not necessarily.
>
> And there are many many examples from other languages of what can go wrong
>> when non-standard libraries compete.
>>
>
> Hmm. Okay, yes. But what about healthy competition? Isn’t that good as
> well? In which context you get bad results? Can you change the system s.t.
> you encourage good competition?
>

i think in open source, competition is mostly beneficial when you have one
old monopoly that’s become lethargic and a new more energetic project
upends it, i.e. gcc vs clang. You get a new improved tool, and the old
project also gets a wakeup call, which is why you’ve seen such a big
improvement in recent versions of gcc. Where there is no such incumbent,
and everyone is starting from scratch, it becomes counterproductive.


>
> As for important voices indexing the tools people use the most, I don’t
>> see that happening.
>>
>
> This is easier than it seems. The Compatibility Suite is already an index
> of important libraries.
>
> Regarding the other problems I see with this proposal: how will you attend
> the necessities of so many diverse groups? You’d need a whole...
> consortium, of sorts. You can’t have just a leader: no one knows the
> context of all the users.
>
>
The Compatibility Suite suffers from licensing issues which prevents a lot
of important libraries from being listed in it. GPL libraries are
effectively excluded from it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

On Tue, Nov 7, 2017 at 12:18 PM, Félix Fischer via swift-evolution <
swift-evolution@swift.org> wrote:

> Hmm. I kind of like the idea, but not really. I think it has a fundamental
> flaw: centralization.
>
> You see, the StdLib can be commanded by a central authority (the core
> team) and hear the needs of the general community (through swift-evolution
> and such) because, among other things, it’s small. The StdLib solves common
> and well-understood problems. Most of the solutions it provides are optimal
> for all use cases.
>
> This is fundamentally different from a non-StdLib. If I understood your
> idea correctly, it would be the complement of StdLib; it will be big and it
> will attend problems that are not well-understood or whose solutions have
> many differrying  approaches depending on the users’ neccessities (think
> Geometry). Therefore, a correct and complete approach would inevitably have
> to:
> - Know the needs of all the relevant user groups and balance their
> priorities.
> - Contain all the important and complementary solutions.
>
> This is very hard to achieve in a centralized system. Not impossible, but
> very resource-intensive.
>
> You can achieve something similar by letting the community grow and by
> encouraging a good environment. People will the build the tools they need,
> and the important voices will index the tools people use the most. That
> makes them good, as well as easily findable. It’s not perfect either, but
> it’s more efficient in my opinion.
>
> — Félix Fischer
>

People tend to build the tools they need, but not what other people need.
And there are many many examples from other languages of what can go wrong
when non-standard libraries compete. As for important voices indexing the
tools people use the most, I don’t see that happening.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

[Kelvin Ma via swift-evolution]

This is something I have been pushing for for some time now and I am glad
to see some more force behind it. There are multiple prior threads about
this topic you should probably familiarize yourselves with for background:

https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20160125/007815.html

https://lists.swift.org/pipermail/swift-evolution/
Week-of-Mon-20170731/038401.html

Since it looks like cross-module inlining/specialization is slated for
Swift 5 I believe now is a good time to get such an effort started as this
was really the only *technical* barrier preventing such libraries from
being written in the past.


On Tue, Nov 7, 2017 at 11:54 AM, Dave DeLong via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi Swift-Evolution,
>
> The Standard Library's goal is to be small and targeted. However, many
> aspects of Apple-provided frameworks need or offer opportunities for
> improvement or wholesale replacement. These enhancements lie beyond the
> scope of the Standard Library.
>
> To address this, we'd like to propose the idea of a "Non-Standard
> Library"; this would be a library that ships with a regular installation of
> Swift, but is not imported into .swift files by the compiler, unless
> explicitly requested by the developer.
>
> We are proposing a well-organized effort to parallel the Standard Library
> without putting additional implementation responsibilities onto the core
> team. This effort would mitigate what we see as platform-independent
> requirements that provide native Swift implementations that aren't
> burdened by Apple history.
>
> *Mission Statement*
>
> We propose to create an open-sourced "Non-Standard Library" effort that
> coexists with, coordinates with, and is blessed by the open source Swift
> development community. The "Non-Standard Library" will offer a
> well-curated, high-value collection of routines, types, and documentation
> to support Swift development on all platforms.
>
> *Goals*
>
> The main goals of this effort would be:
>
>- Alleviate pressure on the Core Team while providing the developer
>community with functionality that normally falls under Apple's internal
>development umbrella.
>- Deliver authoritative, reliable, and regularly updated libraries
>avoiding issues faced by third-party dependencies.
>- Provide oversight, organization, and full community involvement to
>ensure its components are worthy, maintained, and passing a bar of need and
>excellence.
>
> *Suggested Libraries*
>
> There are several areas we think that are ripe for improvement and
> implementation as a non-standard library, such as (but not limited to):
>
>- A BigNum library
>- A full-featured Random library
>- A simplified date/time library
>- A library for manipulating paths (that is not based on URL or String)
>- An expanded Swift-native Geometry library and so forth.
>
> Random is currently being discussed for inclusion into the stdlib. I’m
currently developing  a modern URI type to
replace the Foundation type.


> The scope and extent of the sublibraries would be proposed and debated on
> a parallel Non-Standard Library Evolution development list.
>
> *Coordination*
>
> This effort would be fully coordinated with the Swift development team,
> respecting the team's existing commitments and responsibilities. We would
> request an Apple body to act as an official coordinator, enabling both
> oversight of this effort and to expose Apple-sourced suggestions to
> the Non-Standard community for action.
>

I love Apple but is Apple oversight really going to be beneficial enough to
warrant the additional bureaucratic overhead?


>
> *Next Steps*
>
> To proceed, we need a general community consensus that this effort is
> worth the significant overhead it would involve.
>
> We must then:
>
>- Select a project lead, who appoints technical leaders from the
>community.
>
> Yes

>
>- Recruit a core team, a small group responsible for strategic
>direction, pulled from experienced members well versed in contributing to
>Swift-dev.
>
> Yes

>
>- Establish a Non-Standard Swift Evolution process, based on the one
>that is currently followed by Swift Evolution. Following SE practices will
>guarantee a consistent and excellent language experience for those
>developers including the Non-Standard library into their projects.
>
> I disagree. Swift evolution is incredibly brittle and bureaucratic, it
only works for the stdlib because it is relatively small and most of it has
already been solidified. Any non-standard library initiative would easily
overwhelm the bandwidth of a mailing list. Project leads should have
considerably more autonomy than for the stdlib.

>
>- Build a Non-Standard Swift Evolution repository home.
>
> Yes, and might I add this is a lot more important than most people seem to
acknowledge.

>
>- Adopt a code license, based on Swift's current 

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

[Kelvin Ma via swift-evolution]

hot take: i use the second one a lot but only because i always forget the
first one exists. So I type the = nil just to “be sure”.

On Mon, Nov 6, 2017 at 4:33 PM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> Right now, the following two declarations are equivalent:
>
> struct S {
>   var x: Int?
> }
>
> struct S {
>   var x: Int? = nil
> }
>
> That is, mutable bindings of sugared optional type (but not Optional!)
> always have a default value of ‘nil’. This feature increases the surface
> area of the language for no good reason, and I would like to deprecate it
> in -swift-version 5 with a short proposal. Does anyone feel strongly about
> giving it up? I suspect most Swift users don’t even know it exists.
>
> Slava
> ___
> 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] [SPM] Roadmap?

[Kelvin Ma via swift-evolution]

On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi,
>
> Is there any news about features that are willling to be integrated into
> SPM 5?
> Those I see the most relevant:
> - iOS support
> - Some kind of configuration/settings support (debug, release, ...)
>
> I'd like to hear about it from maintainers, especially if there's a
> priority order we should follow.
>
>
> Hi all,
>
> (CC-ing swift-build-dev, which is the SwiftPM-specific list and is the
> best way to get the SwiftPM core team's attention)
>
> The SwiftPM core team has been discussing our plans for SwiftPM 5, and
> expect to publish a roadmap of the features we're most likely to pursue
> this year. As always, we welcome proposals and contributions for features
> the community would most like to see.
>
> Regarding the specific features that have been mentioned in this thread:
>
> – *iOS support*
>
> I think that this will be best provided by native IDE integration.
> However, in the meantime, I'd welcome contributions to help improve Xcode's
> project generation support.
>
> – *Xcode integration*
>
> I think this will be very important for widespread SwiftPM adoption by the
> Apple-platform developer community.  My previous comments on 2017/6/5 to
> this list are still the latest word on this:
>
> Xcode 9 lays the groundwork for first-class, native support in Xcode for
> Swift packages with the preview version of its new build system. This build
> system provides the flexibility and extensibility needed to allow Xcode to
> support new build models, such as Swift packages. Additionally,
> considerable work has gone into the SwiftPM library vended by the SwiftPM
> project, which will support integrating Swift packages into tools like
> Xcode.
>
>
> I'll note that as Xcode's new build system is still a "preview", further
> work will be needed there before it replaces the old build system. As Xcode
> is not part of the open source project, forward-looking schedules aren't
> something I can discuss.
>
> – *Build settings and configuration support*
>
> The SwiftPM core team has done some work on a proposal for this, and we're
> looking forward to getting this into a publishable state and discussing it
> with the community.
>
> – *Submodules*
>
> Can you elaborate on exactly what you'd like to see here? Offhand I don't
> recall seeing any feature requests in this area.
>

I think submodules means slightly different things to different people but
to me i imagine something like “modules that get compiled together as a
unit”, i.e., there are no ABI boundaries between submodules.


>
> – *Better support for including and linking C libraries*
>
> I'd also like to see this, and welcome proposals / contributions.
>

It’d be great to be able to stick an #include path and a linker flag string
into Package.swift instead of creating empty c modules that just include
system headers. right now this means you have to use a makefile (or
up-arrow in the terminal to get the linker flags back) to compile Swift
projects that depend on system libraries.


>
> – *A swift test command that can execute arbitrary testing code*
>
> As I recall, where the core team had left off on this was a discussion of
> what testability model were going to propose for SwiftPM (specifically,
> handling Swift's -enable-testing flag when needed, but minimizing
> unnecessary rebuilds from using that flag vs. having it off for release
> builds). IIRC, we were considering explicitly modeling "white box" (which
> needs -enable-testing) vs "black box" tests. It's been a little while since
> we last discussed this topic, so if anyone wants this urgently, feel free
> to start a public conversation about this. Any discussion of this should
> also involve the XCTest developers (via swift-corelibs-dev).
>

> – *Help us manage symbol versioning and availability*
>
> Can you elaborate on what you'd like to see here?
>

I only bring this up because there’s been a lot of talk about library
evolution, and it is still easy for you to accidentally break your ABI in
an unintended manner as nothing in the compiler really checks this. It’d be
nice if the SPM took on a bigger role in checking ABI compatibility.

Something else I think will become important to have in the SPM is a better
name conflict resolution system. Right now if you depend on two modules
(even indirectly) that have the same name there’s really nothing you can
do. The SPM should have something like an “import as” system where we can
rebind a conflicting module to a new local name.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] f suffix for float32 literals, h suffix for float16 literals

[Kelvin Ma via swift-evolution]

On Fri, Nov 3, 2017 at 2:05 PM, Steve Canon via swift-evolution <
swift-evolution@swift.org> wrote:

> If/when 16b floats were added to the standard lib, you would just write:
>
> let vertexData: [Float16] = [ 1, 0, 0.5, 1 ]
>
> I should note that something like vertex coordinates is usually better
> modeled with a more specific type than [Float], like SCNVector4 or
> simd.float4 or your own type, which also solves this problem:
>
> import SceneKit
> let vertexData = SCNVector4(1, 0, 0.5, 1)
>
> import simd
> let vertexData = float4(1, 0, 0.5, 1)
>
> (NB both of these frameworks are Apple-specific).
>
> - Steve
>
> Sent from my iPhone
>

If @_fixed_layout was supported this would be sensible, but most graphics
frameworks expect a plain buffer of floats and the packing order is
implicit. We can’t model vertex vectors with Swift structs because we can’t
safely pointer-cast them to an array of floats.


>
> On Nov 3, 2017, at 14:58, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> You can write this for the first thing that you want:
>
> let vertexData: [Float] = [1.0, 0.0, 0.5, 1.0]
>
> I don't know enough about 16-bit floats to comment on those.
>
>
> On Fri, Nov 3, 2017 at 11:26 AM nick ralabate via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I think it would be helpful for graphics programmers to specify vertex
>> data inline without surrounding every value with Float(4.0).
>>
>> Something like this:
>>
>> let vertexData = [ 1.0f, 0.0f, 0.5f, 1.0f ]
>>
>> Also, it would be great if Swift had a type for half-floats to match the
>> iPhone GPU:
>>
>> let vertexData = [ 1.0h, 0.0h, 0.5h, 1.0h]
>>
>>
>> Thanks!
>> ___
>> 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] “Integer” protocol?

[Kelvin Ma via swift-evolution]

On Wed, Nov 1, 2017 at 12:15 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, Nov 1, 2017 at 07:24 Daryle Walker  wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Oct 31, 2017, at 10:55 PM, Xiaodi Wu  wrote:
>>
>> Right, these issues were discussed when the proposal was introduced and
>> reviewed three times. In brief, what was once proposed as `Integer` was
>> renamed `BinaryInteger` to avoid confusion in name between `Integer` and
>> `Int`. It was also found to better reflect the semantics of the protocol,
>> as certain functions treated the value not merely as an integer but
>> operated specifically on its binary representation (for instance, the
>> bitwise operators).
>>
>> Do not confuse integers from their representation. Integers have no
>> intrinsic radix and all integers have a binary representation. This is
>> distinct from floating-point protocols, because many real values
>> representable exactly as a decimal floating-point value cannot be
>> represented exactly as a binary floating-point value.
>>
>>
>> Abstractly, integers have representations in nearly all real radixes. But
>> mandating base-2 properties for a numeric type that uses something else
>> (ternary, negadecimal, non-radix, etc.) in its storage is definitely
>> non-trivial. Hence the request for intermediate protocols that peel off the
>> binary requirements.
>>
>
> Not only binary properties, but specifically two’s-complement binary
> properties. You are correct that some operations require thought for
> implementation if your type uses ternary storage, or for any type that does
> not specifically use two’s-complement representation internally, but having
> actually implemented them I can assure you it is not difficult to do
> correctly without even a CS degree.
>
> Again, one must distinguish between the actual representation in storage
> and semantics, which is what Swift protocols guarantee. The protocols are
> totally agnostic to the internal storage representation. The trade-off for
> supporting ternary _semantics_ is an additional set of protocols which
> complicates understanding and use in generic algorithms. I am not aware of
> tritwise operations being sufficiently in demand.
>

Before everyone gets carried away with these protocols, can I ask what the
real use case for ternary integers is? Also I’m not a fan of bikeshedding
protocols for things that don’t exist (yet).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] stack classes

[Kelvin Ma via swift-evolution]

I’m highly supportive of this, but this pitch is incomplete. Unless we
restrict stack-classes to be non-escaping, and non copyable, at the minimum
we need to force the user to implement a copy initializer as well as deinit.
If we also want to support moves, this could make the compiler diagnostics
more complex since now it’s possible for a variable to be deinitialized
before the end of a block. Also as a nit, I would rather such a thing use
the struct keyword as I associate the keyword class in Swift with heap
indirection.

On Fri, Oct 27, 2017 at 10:49 AM, Gwendal Roué via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello,
>
> It looks like you want compiler guarantees that an object will be
> "deinited" at the end of a syntactic block:
>
> func f() {
> let a = Object()
> ...
> // <- guarantee that a.deinit is called here
> }
>
> Currently, Swift does not grant such guarantee. If the object gets
> retained somewhere, its deallocation is postponed:
>
> var storage: [Object] = []
> func f() {
> let a = Object()
> storage.append(a)
> // <- a.deinit is not called here
> }
>
> With your proposal, the code above would not compile.
>
> The current Swift way to guarantee "cleanup" tasks is the `defer`
> statement:
>
> func f() {
> let a = Object()
> defer { a.cleanup() }
> ...
> }
>
> But this has several defects: object is not fully responsible of its
> state, and one can get "zombie" values that stay around:
>
> var storage: [Object] = []
> func f() {
> let a = Object()
> defer { a.cleanup() } // <- can be forgotten
> storage.append(a) // <- storage will contain "zombie"
> object
> }
>
> So I understand how it looks like Swift does not currently support what
> C++ programmers are used to when they mix RAII with guaranteed stack
> allocation. Note, though, that in C++ guaranteed stack allocation comes for
> the declaration of a value, not from its type.
>
> Is it the correct context of your pitch? Given the immense C++ experience
> of Swift designers, this is surely something they know pretty well. I don't
> know why they did not bring this to Swift. This question itself is an
> interesting topic!
>
> Gwendal
>
>
> > Le 27 oct. 2017 à 15:27, Mike Kluev via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >
> > if it wasn't already discussed here is the preliminary proposal, if it
> was then my +1 to the feature.
> >
> > i propose we have an explicit apparatus to denote classes having stack
> storage.
> >
> > stack class StackObject { // guaranteed to be on stack
> > }
> >
> > class NonStackObject { // is not guaranteed to be on stack, can be on
> heap as well
> > }
> >
> > this is for performance reasons. sometimes what we need is “structs with
> deinit” and as this is not going to happen the next best thing could be
> “lightweight” classes. this shall be self obvious, here are few examples:
> >
> > stack class StackObject {
> > var variable = 0
> >
> > func foo() {
> > print(“i am ok to live on stack”)
> > }
> > }
> >
> > stack class BadObject {
> > var variable = 0
> >
> > func foo() {
> > DispatchQueue.main.async {  // error: can’t be a stack class
> > self.variable = 1
> > }
> > }
> > }
> >
> > class NonStackObject {
> > …
> > }
> >
> > foo() {
> > let stackObject = StackObject()
> >
> > DispatchQueue.main.async {
> > stackObject.foo()  // error: can’t use a stack object in this
> context
> > }
> > }
> >
> > ___
> > 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] Making capturing semantics of local functions explicit

[Kelvin Ma via swift-evolution]

i support this™

On Wed, Oct 25, 2017 at 6:41 AM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> I got bit again by a sneaky memory leak concerning local functions and
> would like to discuss a small language change. I vaguely remember this
> being discussed in the past, but can’t find the thread (if anybody could
> point me to it, I’d appreciate it). Basically, here’s an example of the
> leak:
>
> class A {
> func foo() {
> func local() {
> bar()
> }
>
> methodWithEscapingClosure { [unowned self] _ in
> self.bar()
> local() // this leaks because local captures self}
> }
>
> func bar() {
> }
> }
>
>
> Its sneaky because local’s capturing of self is not obvious if you’ve
> trained your brain to watch out for calls prefixed with self. I would
> suggest having the compiler force users to make self capturing explicit,
> the same way it does for closures:
>
> class A {
> func foo() {
> func local() {
> bar() // error: Call to method ‘bar' in function ‘local' requires 
> explicit 'self.' to make capture semantics explicit
> }
>   // ...
> }
> }
>
>
> What do you think?
>
> David.
>
>
> ___
> 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: Member lookup on String should not find members of NSString

[Kelvin Ma via swift-evolution]

I don’t think anyone is really looking at that at the time but +1 to
bringing NSString functionality to String. This is something that gets
talked about a lot but no one has really sat down to outline what such an
API would look like.

On Wed, Oct 25, 2017 at 3:24 PM, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> I think to maintain source compatibility, the old behavior would be
> preserved until/if we remove -swift-version 4 mode. By deprecating it
> though, we won’t have to devote as much time to maintaining it going
> forward.
> >
> > I think the point is that some of the APIs should continue to be
> offered, but directly rather than via NSString.  We need an analysis of
> what APIs are affected that includes recommendations on which to deprecate
> and which to replace.  We can’t make an informed decision without that.
>
> This is also closely linked to the new String APIs which the String
> Manifesto touched upon but never got implemented. It’d be nice to know what
> plans the Standard Library team has in that regard for Swift 5.
>
> >>
> >> Slava
> >>
> >>> On Oct 24, 2017, at 3:54 PM, Philippe Hausler 
> wrote:
> >>>
> >>> I think any serious proposal with the removal of APIs would need to
> consider source compatibility and to do so you should likely audit the API
> surface area that is being offered (and replace it via the
> NSStringAPI.swift extension)
> >>>
>  On Oct 24, 2017, at 3:12 PM, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  Perhaps you could write up a proposal to outline the missing
> functionality :-)
> 
>  Slava
> 
> > On Oct 24, 2017, at 3:09 PM, Jonathan Hull  wrote:
> >
> > I would feel better about it if String gained a lot of the utility
> of NSString (so that we don’t have to go to NSString all the time for
> methods)
> >
> > Thanks,
> > Jon
> >
> >> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Hi,
> >>
> >> Members of NSString, except those defined in Foundation, are
> available on values of type String. For example,
> >>
> >> extension NSString {
> >> @objc func foo() {}
> >> }
> >>
> >> let s: String = “hello”
> >>
> >> s.foo()
> >>
> >> We don’t do this for any other bridged types, for instance NSArray
> methods are not imported as Array methods. It’s literally a special case in
> the type checker for member lookup on String.
> >>
> >> This behavior doesn’t really much sense conceptually and it was put
> in as a stop-gap in Swift 1 to beef up the String API. I would like to
> phase it out as follows:
> >>
> >> - Unconditional warning in Swift 4.1, with a fixit to insert an ‘as
> NSString’ cast
> >> - Error in Swift 5 with -swift-version 5
> >>
> >> What does everyone think about this?
> >>
> >> Slava
> >> ___
> >> 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
>
> ___
> 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] Standard error?

[Kelvin Ma via swift-evolution]

This has been on my wishlist for a long time and I don’t think it’s in the
Swift stdlib. You have to import Darwin/Glibc.

On Wed, Oct 25, 2017 at 3:51 PM, Daryle Walker via swift-evolution <
swift-evolution@swift.org> wrote:

> Been looking at the Swift standard library pages at Apple’s website.
> There’s “print” and “readLine” for I/O to/from standard output/input. Put
> there seems to be no function for standard error. The “print” function has
> an overload for custom streams, but there doesn’t seem to be an object that
> represents standard error that could go there.
>
> Is there a TextOutputStream object for standard error? Or does that have
> to be added? I wonder if it should be a global or a type-level property
> somewhere?
>
> Sent from my iPad
> ___
> 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] [SPM] Roadmap?

[Kelvin Ma via swift-evolution]

Since this list is dominated by iDevice developers, as a Linux support
advocate I’d like to see better support for including and linking C
libraries (please no more shim hacks), and a swift test command that can
execute arbitrary testing code. Since library ABI is something that we’re
trying to iron out for Swift 5, I’d also like to see a SPM that helps us
manage symbol versioning and availability.

On Mon, Oct 23, 2017 at 2:16 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> I would like Xcode integration 😀
>
> -- Howard.
>
> On 24 Oct 2017, at 4:43 am, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’d be happy if we’d get iOS support and submodules :)
>
>
> Am 23. Oktober 2017 um 19:41:37, Jean-Christophe Pastant via
> swift-evolution (swift-evolution@swift.org) schrieb:
>
> Hi,
>
> Is there any news about features that are willling to be integrated into
> SPM 5?
> Those I see the most relevant:
> - iOS support
> - Some kind of configuration/settings support (debug, release, ...)
>
> I'd like to hear about it from maintainers, especially if there's a
> priority order we should follow.
>
> Regards,
>
>
> ___
> 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] [Draft] Rename Sequence.elementsEqual

[Kelvin Ma via swift-evolution]

I’ve always hated the use of the word “lexicographically” in that method 1)
because lexicographically is hard to spell, and 2) because it’s weird to
say that an unordered collection has a lexicographical order. But this
change is probably for the best.

On Thu, Oct 12, 2017 at 6:24 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> Rename Sequence.elementsEqual
>
>- Proposal: SE-
>
>- Authors: Xiaodi Wu 
>- Review Manager: TBD
>- Status: *Awaiting review*
>
> 
> Introduction
>
> The current behavior of Sequence.elementsEqual is potentially confusing
> to users given its name. Having surveyed the alternative solutions to this
> problem, it is proposed that the method be renamed to Sequence.
> lexicographicallyEquals.
> 
> Motivation
>
> As outlined by Ole Begemann
> , use of
> Sequence.elementsEqual(_:) can lead to surprising results if the
> sequences compared are unordered:
>
> var set1: Set = Set(1...5)var set2: Set = Set((1...5).reversed())
>
> set1 == set2 // trueset1.elementsEqual(set2) // false
>
> This result does reflect the *intended and documented* behavior of the
> elementsEqual(_:) method, which performs a *lexicographical* elementwise
> comparison. That is, the method first compares set1.first to set2.first,
> then (if the two elements compare equal) compares the next element stored
> internally in set1 to the next element stored internally in set2, and so
> on.
>
> In almost all circumstances where a set is compared to another set, or a
> dictionary is compared to another dictionary, users should use == instead
> of elementsEqual(_:).
>
> Proposed
> solution
>
> The proposed solution is the result of an iterative process of reasoning,
> presented here:
>
> The first and most obvious solution is to remove the elementsEqual(_:)
> method altogether in favor of ==. This prevents its misuse. However,
> because elementsEqual(_:) is a generic method on Sequence, we can use it
> to compare an instance of UnsafeBufferPointer to an instance of [Int].
> This is a useful and non-redundant feature which would be eliminated if the
> method is removed altogether.
>
> A second solution  is to
> create overloads that forbid the use of the elementsEqual(_:) method
> specifically in non-generic code. This would prevent misuse in non-generic
> code; however, it would also forbid legitimate mixed-type comparisons in
> non-generic code while failing to prevent misuse in generic code. The
> solution also creates a difference in the behavior of generic and
> non-generic code calling the same method, which is potentially confusing,
> without solving the problem completely.
>
> A third solution is to dramatically overhaul the protocol hierarchy for
> Swift sequences and collections so that unordered collections no longer
> have members such as first and elementsEqual(_:). However, this would be
> a colossal and source-breaking undertaking, and it is unlikely to be
> satisfactory in addressing all the axes of differences among sequence and
> collection types:
>
>- Finite versus infinite
>- Single-pass versus multi-pass
>- Ordered versus unordered
>- Lazy versus eager
>- Forward/bidirectional/random-access
>
> A fourth solution is proposed here. It is predicated on the following
> observation:
>
> *Another method similar to elementsEqual(_:) already exists on Sequence
> named lexicographicallyPrecedes(_:). Like first, elementsEqual(_:),
> drop(while:), and others, it relies on the internal order of elements in a
> manner that is not completely suitable for an unordered collection.
> However, like first and unlike elementsEqual(_:), this fact is called out
> in the name of the method; unsurprisingly, like first and unlike
> elementsEqual(_:), there is no evidence that lexicographicallyPrecedes(_:)
> has been a pitfall for users.*
>
> This observation suggests that a major reason for confusion over
> elementsEqual(_:) stems from its name. So, *it is proposed that
> elementsEqual(_:) should be renamed to lexicographicallyEquals(_:)*. The
> function will remain somewhat of a poor fit for unordered collections, but
> no more so than many other methods that cannot trivially be removed from
> the API of unordered collections (as discussed above). The key is that,
> with such a renaming, the behavior of this method will no longer be
> confusing.
>
> Detailed
> design
>
> extension Sequence where Element : Equatable {
>   @available(*, deprecated, message: "Use '==' if possible to c

Re: [swift-evolution] commas optional

[Kelvin Ma via swift-evolution]

On Thu, Oct 12, 2017 at 6:20 PM, Xiaodi Wu  wrote:

> On Thu, Oct 12, 2017 at 2:47 PM, Jarod Long via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I don't really expect this sort of syntactic sugar to be popular enough
>> to make it through swift-evolution, and I don't think it's worth the
>> distraction from more important priorities at this time, but for what it's
>> worth, I've enjoyed this feature in other languages that support it. It
>> plays a small part in making code more focused by eliminating unnecessary
>> syntax.
>>
>> I could be wrong, but I'm not so sure that this would actually be source
>> breaking. Even if you have something like this:
>>
>> let points = [
>> Point(
>> x: 1.0,
>> y: 2.0
>> ),
>> Point(
>> x: 3.0,
>> y: 4.0
>> )
>> ]
>>
>> Proper implementation of this feature wouldn't suddenly interpret
>> `Point(` as its own element.
>>
>
> There are those of us who respect the 80-character line and break
> expressions across lines:
>
> let x = [
>   NSVeryVeryVeryLongType
> .veryVeryVeryLongProperty +
>   NSVeryVeryVeryLongType2
> .veryVeryVeryLongProperty2,
> ]
>
> It would be a pleasant surprise if a grammar with optional commas can
> avoid blowing up existing code; I'm quite doubtful.
>
>
>
An argument against optional commas,, or an indictment of overly verbose
Foundation APIs… 🤔🤔🤔
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] commas optional

[Kelvin Ma via swift-evolution]

a semicolon is a purely syntactic delimiter, the comma on the other hand
corresponds to physical elements in a collection. I think the two are more
different than you suggest.

On Thu, Oct 12, 2017 at 1:50 PM, Dave Yost via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Speaking as a huge fan of optional semicolons...
>
>
> This seems clear:
>
>  semicolon : sequence of statements
>   :: comma : sequence of elements in an array literal
>
> and so it occurred to me that this should hold:
>
>  A semicolon : the last statement on a line.
>   :: A comma : the last array element on a line.
>
>   ∴  A comma after the last array element on a line should be optional.
>
> and these should be legal Swift:
>
>   let list = [
>   1
>   2
>   ]
>
>   let dict = [
>   1 : 2
>   2 : 3
>   ]
>
> equivalent to:
>
>   let list = [ 1, 2 ] ; let dict = [ 1 : 2, 2 : 3 ]
>
>
> Or, as the Language Reference would say:
>
> A semicolon (;) can optionally appear after any statement and is used to
> separate multiple statements if they appear on the same line.
>
>
> A comma (,) can optionally appear after any element of an array literal
> and is used to separate multiple elements if they appear on the same line.
>
>
> Or:
>
> A semicolon (;) separates statements but is optional after the last
> statement on a line.
>
>
> A comma (,) separates elements of an array literal but is optional after
> the last element on a line.
>
>
>
>
> ___
> 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

[Kelvin Ma via swift-evolution]

Did not know you could do that. Still doesn’t change the fundamental
problems with that syntax though. I think that we could enforce a
precondition that overrunning the left hand slice is not allowed, but idk
if subscript notation is worth all that trouble.

On Thu, Oct 12, 2017 at 3:36 AM, Ole Begemann  wrote:

>
> On 12. Oct 2017, at 01:17, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky  brackettrozin...@gmail.com> wrote:
>
>> On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Yes, a 0-ary operator like that would have to be hard baked into the
>>> language itself.
>>>
>>
>> Actually, you can just make a subscript which takes a function as an
>> argument, and call it by passing in the ellipsis operator.
>>
>
> I mean,,, you can,,, but that’s kind of weird
>
>
> That's exactly how the [...] notation is implemented in the stdlib. Toni
> Suter wrote a great article about it: https://tonisuter.com/
> blog/2017/08/unbounded-ranges-swift-4/
>
>
___
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

[Kelvin Ma via swift-evolution]

On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Yes, a 0-ary operator like that would have to be hard baked into the
>> language itself.
>>
>
> Actually, you can just make a subscript which takes a function as an
> argument, and call it by passing in the ellipsis operator.
>
> Nevin
>
>
>
>  Of course, the subscript notation has much more serious problems, there
>> is no way to allow one-sided subscripting, but disallow two-sided
>> subscripting for the memory API, while still allowing two-sided
>> subscripting for ordinary slicing operations. This is why I still think
>> at:from: is the much better syntax.
>>
>> On Wed, Oct 11, 2017 at 3:01 PM, Nevin Brackett-Rozinsky <
>> nevin.brackettrozin...@gmail.com> wrote:
>>
>>> I believe Kelvin was asking about the usage of ellipsis *by itself*, as
>>> in Xiaodi’s example, “newBuffer[...]”.
>>>
>>> Nevin
>>>
>>
I mean,,, you can,,, but that’s kind of weird
___
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

[Kelvin Ma via swift-evolution]

I should also add I think I remember the String people trying to add
collection[] empty subscripts to the language but I don’t remember that
ever going through.

On Wed, Oct 11, 2017 at 3:15 PM, Kelvin Ma  wrote:

> Yes, a 0-ary operator like that would have to be hard baked into the
> language itself. Of course, the subscript notation has much more serious
> problems, there is no way to allow one-sided subscripting, but disallow
> two-sided subscripting for the memory API, while still allowing two-sided
> subscripting for ordinary slicing operations. This is why I still think
> at:from: is the much better syntax.
>
> On Wed, Oct 11, 2017 at 3:01 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> I believe Kelvin was asking about the usage of ellipsis *by itself*, as
>> in Xiaodi’s example, “newBuffer[...]”.
>>
>> Nevin
>>
>>
>> On Wed, Oct 11, 2017 at 2:42 PM, Anders Ha via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> ICYMI, SE-0172 was the proposal of one sided range and it has been
>>> implemented as part of 4.0.
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposa
>>> ls/0172-one-sided-ranges.md
>>>
>>>
>>> Regards
>>> Anders
>>>
>>> > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu 
>>> wrote:
>>> > On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> > Hi guys, after passing SE 184 (A), I want to get some community
>>> feedback on the next phase of our Swift pointer overhaul which is a partial
>>> initialization/deinitialization API for UnsafeMutableBufferPointer and
>>> UnsafeMutableRawBufferPointer.
>>> >
>>> > You can read about the originally proposed API in the original SE 184
>>> document, basically we use an at:from: system for binary memory state
>>> operations where the at: argument supplies the start position in the
>>> destination buffer, and the from: source argument supplies the number of
>>> elements to copy/move into the destination.
>>> >
>>> > newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
>>> > newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..<
>>> self.zero])
>>> >
>>> > Some other proposed APIs include using subscript notation, and writing
>>> a special buffer slice type and a corresponding protocol to handle this.
>>> >
>>> > newBuffer[0...].moveInitialize(from:
>>> self.buffer[self.zero...   ])
>>> > newBuffer[self.zero ... self.zero << 1].moveInitialize(from:
>>> self.buffer[0 ..< self.zero])
>>> >
>>> > Fully embracing slice notation and SwiftLint style, this could be:
>>> >
>>> > newBuffer[...].moveInitialize(from: buffer[zero...])
>>> > newBuffer[zero...].moveInitialize(from: buffer[..>> >
>>> > Is the solo ellipsis operator even valid Swift syntax? And I agree
>>> this would look nice, but as others have mentioned, Swift has the
>>> convention that the one-sided slice operators are equivalent to start ...
>>> endIndex and startIndex ... end. And that seems to strongly suggest that
>>> the method would initialize the entire range which is not what we want to
>>> communicate.
>>> >
>>> >
>>> > A hypothetical comparison of this API, the at:from: API, and the
>>> existing plain pointer API can be found in this basic Swift queue
>>> implementation here if anyone wants to see how this would look in “real”
>>> code. I’m interested in seeing which syntax and which API is preferred as
>>> well as what people would like to do with an expanded Swift buffer pointer
>>> toolbox.
>>> >
>>> > Would you mind rewriting these examples in a more common Swift style
>>> (for instance, SwiftLint/GitHub style)? Everyone is entitled to write code
>>> how they please, but it’s much easier to compare how things “look” when the
>>> overall formatting is more familiar.
>>> >
>>> > I mean the purpose of the example is to compare the call sites of the
>>> actual buffer methods. ignoring the function signatures and instead getting
>>> distracted by brace placement seems like the kind of bikeshedding we should
>>> be discouraging lol.
>>> >
>>> >
>>> >
>>> > ___
>>> > 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] SE-1084 (B): buffer pointer partial initialization API

[Kelvin Ma via swift-evolution]

Yes, a 0-ary operator like that would have to be hard baked into the
language itself. Of course, the subscript notation has much more serious
problems, there is no way to allow one-sided subscripting, but disallow
two-sided subscripting for the memory API, while still allowing two-sided
subscripting for ordinary slicing operations. This is why I still think
at:from: is the much better syntax.

On Wed, Oct 11, 2017 at 3:01 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> I believe Kelvin was asking about the usage of ellipsis *by itself*, as in
> Xiaodi’s example, “newBuffer[...]”.
>
> Nevin
>
>
> On Wed, Oct 11, 2017 at 2:42 PM, Anders Ha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> ICYMI, SE-0172 was the proposal of one sided range and it has been
>> implemented as part of 4.0.
>>
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/0172-one-sided-ranges.md
>>
>>
>> Regards
>> Anders
>>
>> > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> >
>> > On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu  wrote:
>> > On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > Hi guys, after passing SE 184 (A), I want to get some community
>> feedback on the next phase of our Swift pointer overhaul which is a partial
>> initialization/deinitialization API for UnsafeMutableBufferPointer and
>> UnsafeMutableRawBufferPointer.
>> >
>> > You can read about the originally proposed API in the original SE 184
>> document, basically we use an at:from: system for binary memory state
>> operations where the at: argument supplies the start position in the
>> destination buffer, and the from: source argument supplies the number of
>> elements to copy/move into the destination.
>> >
>> > newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
>> > newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..<
>> self.zero])
>> >
>> > Some other proposed APIs include using subscript notation, and writing
>> a special buffer slice type and a corresponding protocol to handle this.
>> >
>> > newBuffer[0...].moveInitialize(from:
>> self.buffer[self.zero...   ])
>> > newBuffer[self.zero ... self.zero << 1].moveInitialize(from:
>> self.buffer[0 ..< self.zero])
>> >
>> > Fully embracing slice notation and SwiftLint style, this could be:
>> >
>> > newBuffer[...].moveInitialize(from: buffer[zero...])
>> > newBuffer[zero...].moveInitialize(from: buffer[..> >
>> > Is the solo ellipsis operator even valid Swift syntax? And I agree this
>> would look nice, but as others have mentioned, Swift has the convention
>> that the one-sided slice operators are equivalent to start ... endIndex and
>> startIndex ... end. And that seems to strongly suggest that the method
>> would initialize the entire range which is not what we want to communicate.
>> >
>> >
>> > A hypothetical comparison of this API, the at:from: API, and the
>> existing plain pointer API can be found in this basic Swift queue
>> implementation here if anyone wants to see how this would look in “real”
>> code. I’m interested in seeing which syntax and which API is preferred as
>> well as what people would like to do with an expanded Swift buffer pointer
>> toolbox.
>> >
>> > Would you mind rewriting these examples in a more common Swift style
>> (for instance, SwiftLint/GitHub style)? Everyone is entitled to write code
>> how they please, but it’s much easier to compare how things “look” when the
>> overall formatting is more familiar.
>> >
>> > I mean the purpose of the example is to compare the call sites of the
>> actual buffer methods. ignoring the function signatures and instead getting
>> distracted by brace placement seems like the kind of bikeshedding we should
>> be discouraging lol.
>> >
>> >
>> >
>> > ___
>> > 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] SE-1084 (B): buffer pointer partial initialization API

[Kelvin Ma via swift-evolution]

On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu  wrote:

> On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi guys, after passing SE 184 (A)
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md>,
>> I want to get some community feedback on the next phase of our Swift
>> pointer overhaul which is a partial initialization/deinitialization API
>> for UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer.
>>
>> You can read about the originally proposed API in the original SE 184
>> document
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md>,
>> basically we use an at:from: system for binary memory state operations
>> where the at: argument supplies the start position in the destination
>> buffer, and the from: source argument supplies the number of elements to
>> copy/move into the destination.
>>
>> newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
>> newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..<
>> self.zero])
>>
>> Some other proposed APIs include using subscript notation, and writing a
>> special buffer slice type and a corresponding protocol to handle this.
>>
>> newBuffer[0...].moveInitialize(from:
>> self.buffer[self.zero...   ])
>> newBuffer[self.zero ... self.zero << 1].moveInitialize(from:
>> self.buffer[0 ..< self.zero])
>>
>
> Fully embracing slice notation and SwiftLint style, this could be:
>
> newBuffer[...].moveInitialize(from: buffer[zero...])
> newBuffer[zero...].moveInitialize(from: buffer[..

Is the solo ellipsis operator even valid Swift syntax? And I agree this
would look nice, but as others have mentioned, Swift has the convention
that the one-sided slice operators are equivalent to start ...
endIndex and startIndex
... end. And that seems to strongly suggest that the method would
initialize the entire range which is not what we want to communicate.


>
> A hypothetical comparison of this API, the at:from: API, and the existing
>> plain pointer API can be found in this basic Swift queue implementation
>> here <https://gist.github.com/kelvin13/0860334278aeab5c1cbaefbefb050268>
>> if anyone wants to see how this would look in “real” code. I’m interested
>> in seeing which syntax and which API is preferred as well as what people
>> would like to do with an expanded Swift buffer pointer toolbox.
>>
>
> Would you mind rewriting these examples in a more common Swift style (for
> instance, SwiftLint/GitHub style)? Everyone is entitled to write code how
> they please, but it’s much easier to compare how things “look” when the
> overall formatting is more familiar.
>

I mean the purpose of the example is to compare the call sites of the
actual buffer methods. ignoring the function signatures and instead getting
distracted by brace placement seems like the kind of bikeshedding we should
be discouraging lol.


>
>
>> ___
>> 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] SE-1084 (B): buffer pointer partial initialization API

[Kelvin Ma via swift-evolution]

Hi guys, after passing SE 184 (A)
,
I want to get some community feedback on the next phase of our Swift
pointer overhaul which is a partial initialization/deinitialization API for
UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer.

You can read about the originally proposed API in the original SE 184
document
,
basically we use an at:from: system for binary memory state operations
where the at: argument supplies the start position in the destination
buffer, and the from: source argument supplies the number of elements to
copy/move into the destination.

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

Some other proposed APIs include using subscript notation, and writing a
special buffer slice type and a corresponding protocol to handle this.

newBuffer[0...].moveInitialize(from:
self.buffer[self.zero...   ])
newBuffer[self.zero ... self.zero << 1].moveInitialize(from: self.buffer[0
..< self.zero])

A hypothetical comparison of this API, the at:from: API, and the existing
plain pointer API can be found in this basic Swift queue implementation here
 if
anyone wants to see how this would look in “real” code. I’m interested in
seeing which syntax and which API is preferred as well as what people would
like to do with an expanded Swift buffer pointer toolbox.
___
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

[Kelvin Ma via swift-evolution]

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.

On Mon, Oct 2, 2017 at 9:43 PM, Slava Pestov  wrote:

> It would be a trivial change to allow @_versioned on private and
> fileprivate declarations, but there are two pitfalls to keep in mind:
>
> - Private symbols are mangled with a ‘discriminator’ which is basically a
> hash of the file name. So now it would be part of the ABI, which seems
> fragile — you can’t move the private function to another source file, or
> rename the source file.
>
> - Similarly, right now a @_versioned function becoming public is an ABI
> compatible change. This would no longer work if you could have private
> @_versioned functions, because the symbol name would change if it became
> public.
>
> For these reasons we decided against “private versioned” as a concept. I
> feel like internal is enough here.
>
> Slava
>
>
> On Oct 2, 2017, at 4:54 PM, Taylor Swift  wrote:
>
> 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] SE-184 Improved Pointers

[Kelvin Ma via swift-evolution]

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 
>  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 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/