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

[David Hart via swift-evolution]

> On 6 Oct 2017, at 06:25, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
>> On 5 Oct 2017, at 20:23, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Oct 5, 2017, at 10:58, Nate Cook via swift-evolution 
>>>  wrote:
>>> 
>>> The edge case is really the same (empty ranges), it’s about what we do with 
>>> the edge case. If we include the methods on integer types, usage will look 
>>> like this:
>>> 
>>> let x = Int.random(in: 0..<5) // 3
>>> let y = Int.random(in: 0..<0) // runtime error
>>> 
>> 
>> These examples are a bit misleading, because they use literals.  Sometimes 
>> they will, sure, but in practice, many use cases would define Int.random(in: 
>> 0..> array.random().
>> 
>> p.s. ideally Int.random(in: 0..<0) would be a compile time error...
>> 
>>> If we only have the collection methods, usage will look like this:
>>> 
>>> let x = (0..<5).random()! // 3
>>> let y = (0..<0).random()! // runtime error
>>> 
>> 
>> I don’t know if it’s a given that we must make randomElement optional. I’m 
>> on the fence as to whether it should be optional vs trap on empty. 
> 
> I vote for making them optional because doing otherwise would be inconsistent 
> with first and last, no?

I want to be able to check for empty at the same time as I get the value, 
exactly like I do first first and last:

if let rand = array.randomElement() {
// use rand
} else {
// handle empty
}

OR

guard let rand = array.randomElement() else {
// handle empty
}

I also like those optional returning properties because it’s a small reminder 
from the type system to check for the corner case (empty) and makes them 
explicit when reading code. With a trapping function, I would often forget to 
handle empty and it wouldn’t jump out at me when reading code.

>> Another option is to shadow randomElement on closed range to be non-optional.
>> 
>>> But my suspicion is that lots of people will write things like this:
>>> 
>>> guard let x = (0..<5).random() 
>>> else { fatalError("not gonna happen") }
>>> 
>>> I’d rather have the numeric methods trap than add the optional unwrapping 
>>> step to every one of these calls. For me, getting a random number and 
>>> picking a random element of a collection are two different operations—where 
>>> it’s common to work with empty collections, especially in generic code, 
>>> trying to get a random value from an empty range is really a programming 
>>> error. I think it’s okay for them to have slightly different semantics.
>>> 
>>> Nate
>>> 
>>> 
 On Oct 5, 2017, at 12:27 PM, Alejandro Alonso  
 wrote:
 
 Rather 0 ..< 0 my bad. I think if we include closedcountable, then there 
 needs to be support for countable, but there are edge cases where users 
 can input invalid ranges for countable. 
 
 Enviado desde mi iPhone
 
 El oct. 5, 2017, a la(s) 12:22, Alejandro Alonso via swift-evolution 
  escribió:
 
> I agree with Ben here because users can still enter an invalid range with 
> the static function. I.E. Int.random(in: 0 ... 0). 
> I would really prefer excluding these static functions from numeric types.
> 
> - Alejandro
> 
> El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution 
>  escribió:
> 
>>> On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution 
>>>  wrote:
>>> 
 On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution 
  wrote:
 
> ```
> extension Int {
>   static func random(in range: Countable{Closed}Range) -> Int
> }
 
 Nice.  Should these be initializers like:
 
 extension Int {
   init(randomIn: Countable{Closed}Range)
 }
 
>>> 
>>> I don’t see much of a case for making it it random(in: 
>>> SpecificCollection) instead of genericCollection.random().
>> 
>> I see a couple points in favor of these static methods (or initializers) 
>> on the numeric types:
>> 
>> 1) The collection method will need to return an optional to match the 
>> semantics of existing methods (like min()). If this is the only method 
>> available, every time someone needs a random value in the range 1...10, 
>> they’ll need to unwrap the result (with either force unwrapping, which 
>> people will complain about, or some kind of conditional binding, which 
>> is its own problem). Even if the semantics are the same (trapping on an 
>> empty range), the user experience of using a non-optional method will be 
>> better.
>> 
>> 2) Floating-point ranges won’t get the collection method, so 

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

[Chris Lattner via swift-evolution]

> On Oct 5, 2017, at 3:57 AM, Dennis Ferguson via swift-evolution 
>  wrote:
> 
> I concur with Taylor and John on this particular issue. As much as I use 
> annotations in my daily work, I wouldn’t want the language cluttered up and 
> there will always be industry unique annotations that would be frustratingly 
> unsupported (e.g. I say “j” and you say “i”). 

Understandable across the world at large, but one of the points of language 
design is to standardize spelling of things.

-Chris


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

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

[David Hart via swift-evolution]

> On 5 Oct 2017, at 20:23, Ben Cohen via swift-evolution 
>  wrote:
> 
> 
>> On Oct 5, 2017, at 10:58, Nate Cook via swift-evolution 
>>  wrote:
>> 
>> The edge case is really the same (empty ranges), it’s about what we do with 
>> the edge case. If we include the methods on integer types, usage will look 
>> like this:
>> 
>> let x = Int.random(in: 0..<5) // 3
>> let y = Int.random(in: 0..<0) // runtime error
>> 
> 
> These examples are a bit misleading, because they use literals.  Sometimes 
> they will, sure, but in practice, many use cases would define Int.random(in: 
> 0.. array.random().
> 
> p.s. ideally Int.random(in: 0..<0) would be a compile time error...
> 
>> If we only have the collection methods, usage will look like this:
>> 
>> let x = (0..<5).random()! // 3
>> let y = (0..<0).random()! // runtime error
>> 
> 
> I don’t know if it’s a given that we must make randomElement optional. I’m on 
> the fence as to whether it should be optional vs trap on empty. 

I vote for making them optional because doing otherwise would be inconsistent 
with first and last, no?

> Another option is to shadow randomElement on closed range to be non-optional.
> 
>> But my suspicion is that lots of people will write things like this:
>> 
>> guard let x = (0..<5).random() 
>> else { fatalError("not gonna happen") }
>> 
>> I’d rather have the numeric methods trap than add the optional unwrapping 
>> step to every one of these calls. For me, getting a random number and 
>> picking a random element of a collection are two different operations—where 
>> it’s common to work with empty collections, especially in generic code, 
>> trying to get a random value from an empty range is really a programming 
>> error. I think it’s okay for them to have slightly different semantics.
>> 
>> Nate
>> 
>> 
>>> On Oct 5, 2017, at 12:27 PM, Alejandro Alonso  
>>> wrote:
>>> 
>>> Rather 0 ..< 0 my bad. I think if we include closedcountable, then there 
>>> needs to be support for countable, but there are edge cases where users can 
>>> input invalid ranges for countable. 
>>> 
>>> Enviado desde mi iPhone
>>> 
>>> El oct. 5, 2017, a la(s) 12:22, Alejandro Alonso via swift-evolution 
>>>  escribió:
>>> 
 I agree with Ben here because users can still enter an invalid range with 
 the static function. I.E. Int.random(in: 0 ... 0). 
 I would really prefer excluding these static functions from numeric types.
 
 - Alejandro
 
 El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution 
  escribió:
 
>> On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>>> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
 ```
 extension Int {
   static func random(in range: Countable{Closed}Range) -> Int
 }
>>> 
>>> Nice.  Should these be initializers like:
>>> 
>>> extension Int {
>>>   init(randomIn: Countable{Closed}Range)
>>> }
>>> 
>> 
>> I don’t see much of a case for making it it random(in: 
>> SpecificCollection) instead of genericCollection.random().
> 
> I see a couple points in favor of these static methods (or initializers) 
> on the numeric types:
> 
> 1) The collection method will need to return an optional to match the 
> semantics of existing methods (like min()). If this is the only method 
> available, every time someone needs a random value in the range 1...10, 
> they’ll need to unwrap the result (with either force unwrapping, which 
> people will complain about, or some kind of conditional binding, which is 
> its own problem). Even if the semantics are the same (trapping on an 
> empty range), the user experience of using a non-optional method will be 
> better.
> 
> 2) Floating-point ranges won’t get the collection method, so either we’ll 
> have inconsistent APIs (random FP value is non-optional, random integer 
> is optional) or we’ll make the FP API optional just to match. Both of 
> those seem bad.
> 
>> One possible reason is if you exclude half-open ranges, only having 
>> CountableClosedRange, then you don’t have to account for the possibility 
>> of an empty collection (via an optional or a trap) because they cannot 
>> be empty. But closed ranges aren’t the currency type – half-open ranges 
>> are. So it’d hit usability if you have to convert from one to t'other 
>> often.
>> 
>> Other possibility is discovery. But given the common use case is “random 
>> element from collection”, I don’t expect this to be an issue as it will 
>> 

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

[Douglas Gregor via swift-evolution]

Hello Swift community,

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md

The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointer: add missing 
methods, adjust existing labels for clarity, and remove deallocation size” 
officially ran September 1…7, 2017. It was a large proposal for which most 
parts received a lot of support, while other parts were contentious. The 
proposal is accepted with revisions:

* Partial initialization/assignment will be removed from this proposal and 
discussed separataely
* Some argument labels will be changed for clarity (“bytes” -> “byteCount”, 
“alignedTo” -> “alignment”)
* The “count” argument to deallocate() will be removed entirely

The proposal has already been updated to reflect these changes. Thank you to 
the proposal author and everyone who participated in the discussion.

Doug,
Review Manager___
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

[Joe Groff via swift-evolution]

> On Oct 4, 2017, at 9:24 PM, Chris Lattner  wrote:
> 
> On Oct 4, 2017, at 9:44 AM, Joe Groff  wrote:
>>> I disagree.  The semantics being proposed perfectly overlap with the 
>>> transitional plan for overlays (which matters for the next few years), but 
>>> they are the wrong default for anything other than overlays and the wrong 
>>> thing for long term API evolution over the next 20 years.
>> 
>> I disagree with this. 'inline' functions in C and C++ have to be backed by a 
>> symbol in the binary in order to guarantee function pointer identity, but we 
>> don't have that constraint. Without that constraint, there's almost no way 
>> that having a fallback definition in the binary is better:
>> 
>> - It becomes an ABI compatibility liability that has to be preserved 
>> forever. 
> 
> This seems like a marginal win at all.  Saying that you want to publish a 
> symbol as public API but not have it be ABI is a bit odd.  What is the 
> usecase (other than the Swift 3/4/5 transition period)?

I think it's a bigger win than you give it credit. If the function only exists 
in client code, then the library can much more aggressively deprecate and 
remove or replace the API, since it only has to worry about source 
compatibility and not deployed binary compatibility. If introducing 
`@inlinable` later further requires new clients to emit-into-client from that 
point on, so that the in-dylib entry point only exists for backward 
compatibility, then you get a free "linked-on-or-after" boundary where you can 
fix quirks or shed compatibility behavior in the inlinable version while 
preserving it in the binary.

>> - It increases binary size for a function that's rarely used, and which is 
>> often much larger as an outlined generic function than the simple operation 
>> that can be inlined into client code. Inlining makes the most sense when the 
>> inlined operation is smaller than a function call, so in many cases the net 
>> dylib + executable size would increase.
> 
> I can see this argument, but you’re basically saying that a sufficiently 
> smart programmer can optimize code size based on (near) perfect knowledge of 
> the symbol and all clients.  I don’t think this is realistic for a number of 
> reasons.  In general, an API vendor has no way to know:
> 
> 1) how many clients it will have, potentially in multiple modules that get 
> linked into a single app.
> 2) on which types a generic function will be used with.
> 3) what the code size tradeoffs ARE, e.g. if you have a large function that 
> doesn’t use the archetype much, there is low bloat.
> 
> Furthermore, we have evidence from the C++ community that people are very 
> eager to mark lots of things inlinable regardless of the cost of doing so.  
> Swift may end up being different, but programmers still have no general way 
> to reason about code size given their declaration and without perfect 
> knowledge of the clients.
> 
> The code of the approach I’m advocating is one *single* implementation gets 
> generated in the module that defines the decl.  This can lead the N 
> instantiations of exactly the same unspecialized code (consider the currying 
> and other cases) in N different modules that end up in an app.  This seems 
> like the right tradeoff.

If we're talking about inlinable functions, then we're already talking about 
functions generally on the small end of the scale, so duplication is less of an 
issue. Furthermore, the duplication hazard only exists at dylib boundaries, 
since among static libraries we can still instantiate all the different 
instantiations of the function as ODR and let the linker fold them. For most 
apps there aren't going to be that many of those boundaries.

>> - It increases the uncertainty of the behavior client code sees. If an 
>> inlinable function must always be emitted in the client, then client code 
>> *always* gets the current definition. If an inlinable function calls into 
>> the dylib when the compiler chooses not to inline it, then you may get the 
>> current definition, or you may get an older definition from any published 
>> version of the dylib. Ideally these all behave the same if the function is 
>> inlinable, but quirks are going to be inevitable.
> 
> You’re saying that “if an API author incorrectly changes the behavior of 
> their inlinable function” that your approach papers over the bug a little bit 
> better.  I don’t see this as something that is important to design around.  
> Not least of which because it will produce other inconsistencies: what if a 
> binary module A is built against the old version of that inlinable function 
> and you app builds against a newer version?  Then you have the two 
> inconsistent versions in your app again.
> 
> More generally though, an API vendor who does this has broken the 
> fragile/inlinable contract, and they therefore invoked undefined behavior - 
> c'est la vie.

The contract doesn't need to be nearly 

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

[Slava Pestov via swift-evolution]

> On Oct 5, 2017, at 1:17 PM, Michael Ilseman via swift-evolution 
>  wrote:
> 
> Another benefit of the always-emit-into-client-and-omit-from-libary-binary is 
> cross-call consistency. A function foo could change in a way such that *all* 
> calls using either the new or old version is fine, but some interleaving of 
> calls to new and old versions is invalid. Having to reason about and test 
> interleaving is very difficult. This further extends to groups of functions 
> that want to maintain a cross-function-group call consistency (e.g. multiple 
> methods on a struct).

This is not true though, because any calls to the inlinable function from 
inside its defining module will always use the ‘latest’ definition.

Or imagine if you link multiple frameworks that all inline different versions 
of an inlinable function. I don’t think there’s a way to make the guarantee you 
described.

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

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

[Michael Ilseman via swift-evolution]

Another benefit of the always-emit-into-client-and-omit-from-libary-binary is 
cross-call consistency. A function foo could change in a way such that *all* 
calls using either the new or old version is fine, but some interleaving of 
calls to new and old versions is invalid. Having to reason about and test 
interleaving is very difficult. This further extends to groups of functions 
that want to maintain a cross-function-group call consistency (e.g. multiple 
methods on a struct).



> On Oct 5, 2017, at 9:32 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
> 
>> On Oct 4, 2017, at 9:15 PM, Chris Lattner > > wrote:
>> 
>> 
>>> On Oct 4, 2017, at 9:36 AM, Joe Groff >> > wrote:
>>> 
>> It wouldn't avoid the complexity, because we want the "non-ABI, 
>> always-emit-into-client" behavior for the standard library. For the 
>> soon-to-be-ABI-stable libraries where @inlinable even matters, such as 
>> the standard library and Apple SDK overlays, there's pretty much perfect 
>> overlap between things we want to inline and things we don't want to 
>> take up binary space and ABI surface in binaries, so the behavior Slava 
>> proposes seems like the right default. 
> 
> I disagree.  The semantics being proposed perfectly overlap with the 
> transitional plan for overlays (which matters for the next few years), 
> but they are the wrong default for anything other than overlays and the 
> wrong thing for long term API evolution over the next 20 years.
 
 Can you elaborate on this? If inlinable functions have public entry 
 points, the version in the framework may or may not be called… because of 
 SIL serialization and inlining. Since the existence of the public entry 
 point doesn’t offer much of a guarantee, it seems desirable to not have 
 the public entry point. For example if the inlinable function is not used 
 elsewhere in the framework, we wouldn’t have to emit it at all. This might 
 make the standard library smaller for instance.
 
 However I’m still waiting for Dave or Jordan to chime in with the original 
 justification for the ‘always emit into client’ behavior. IIRC there was a 
 resilience-related argument too, but I don’t remember what it is now.
>>> 
>>> The suggestion to have this semantics was originally my fault, I believe, 
>>> and it arose from the observation that if we have 'inlinable' backed by a 
>>> symbol in the binary, then we'd also want the 'must be emitted by client' 
>>> attribute. I think 'must be emitted by client' is going to almost always be 
>>> preferable for an inlinable function, though, so it's better to have the 
>>> single attribute with this behavior, only constrained by backward 
>>> deployment.
>> 
>> What is the use case of “must be emitted by client” attribute?  If I imagine 
>> that the Swift 5 standard library is shipped in the OS, I can see cases 
>> where deprecated/legacy shims for Swift3/4 compatibility would be emitted 
>> into the client but not shipped in the OS.  Those seem relatively obscure 
>> though.
> 
> You could just as easily pose the opposite question—what's the use case for a 
> symbol in the dylib when the definition is visible to clients? Evaluating the 
> tradeoffs, we feel like it's better not to unless backward compatibility 
> demands it.
> 
> -Joe
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Roman Levenstein via swift-evolution]

> On Oct 5, 2017, at 12:01 AM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Oh right. @_specialize modifies the original entry point to do runtime 
> dispatch among the possible specializations. So the overhead comes from the 
> unnecessary checks. I guess ideally we would have two versions of 
> @_specialize, one adds the runtime dispatch whereas the other one just 
> publishes static specializations which can be deserialized and used as needed.

The support for publishing static specializations is envisioned in the current 
implementation of @_specialize already, though it is not well tested yet.

If you use the "exported: true" parameter with @_specialize, the body of the 
produced specialization would not be SIL serialized, but it will emitted into 
the object file of the defining module and the specialized function will be 
made available as a public symbol in the object file, so that the clients can 
link against it and invoke it directly. Since clients can refer to this symbol 
now, it cannot be removed in the future versions of the library as it would 
break all such clients linked against it.

@_specialize(exported: true, where K == Int, V == Int)
func foo(dict: Dictionary) {
}

We could also allow for making those exported specializations @inlinable if 
required by the user.

-Roman

> 
> Since @_specialize is not an officially supported attribute though, I would 
> suggest punting this discussion until someone decides to push through an 
> evolution proposal for it. For all intents and purposes, @inlinable is a 
> superset of @_specialized because it defers the specialization decisions to 
> the client.
> 
> Slava
> 
>> On Oct 4, 2017, at 11:47 PM, Taylor Swift > > wrote:
>> 
>> See the thread 
>> 
>>  from july over generic trig functions, where @_specialize() + @_inlineable 
>> had a small but consistent performance penalty relative to @_inlineable 
>> alone.
>> 
>> On Thu, Oct 5, 2017 at 1:32 AM, Slava Pestov > > wrote:
>> 
>> 
>>> On Oct 4, 2017, at 11:04 PM, Taylor Swift >> > wrote:
>>> 
>>> 
>>> 
>>> On Oct 5, 2017, at 12:52 AM, Slava Pestov >> > wrote:
>>> 
 
 
> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution 
> > wrote:
> 
> i’m just tryna follow along here && this is probably a dumb question, but 
> is it possible for a generic function to be emitted as a set of 
> specialized functions into the client, but not inlined everywhere? It can 
> be the case where a large generic function gets slowed down by the large 
> number of generic operations inside it but it doesn’t make sense for it 
> to be inlined completely.
 
 This is already possible. The optimizer doesn’t have to inline an 
 @_inlineable function at its call site; it can emit a call to a 
 specialized version instead.
 
 Slava
>>> 
>>> Is there a reason using @_specialize() and @_inlineable together is slower 
>>> than using @_inlineable by itself?
>> 
>> By specialization, I mean the optimizer pass which takes a function body and 
>> substitutes generic parameters with statically-known types.
>> 
>> I’m not sure what your question means though. Adding a @_specialize 
>> attribute should never make anything slower. Rather it makes the optimizer 
>> eagerly emit specializations of a function in the defining module. You can 
>> think of @_specialize and @inlinable as mostly mutually exclusive; either 
>> you publish the complete function body for clients to optimize as they 
>> please, or you publish a fixed set of specializations.
>> 
>> You might prefer the latter for secrecy (serialized SIL is much closer to 
>> source code than machine code), but the the former enables more general 
>> optimizations.
>> 
>> Slava
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Ben Cohen via swift-evolution]

> On Oct 5, 2017, at 10:58, Nate Cook via swift-evolution 
>  wrote:
> 
> The edge case is really the same (empty ranges), it’s about what we do with 
> the edge case. If we include the methods on integer types, usage will look 
> like this:
> 
> let x = Int.random(in: 0..<5) // 3
> let y = Int.random(in: 0..<0) // runtime error
> 

These examples are a bit misleading, because they use literals.  Sometimes they 
will, sure, but in practice, many use cases would define Int.random(in: 
0.. If we only have the collection methods, usage will look like this:
> 
> let x = (0..<5).random()! // 3
> let y = (0..<0).random()! // runtime error
> 

I don’t know if it’s a given that we must make randomElement optional. I’m on 
the fence as to whether it should be optional vs trap on empty. 

Another option is to shadow randomElement on closed range to be non-optional.

> But my suspicion is that lots of people will write things like this:
> 
> guard let x = (0..<5).random() 
> else { fatalError("not gonna happen") }
> 
> I’d rather have the numeric methods trap than add the optional unwrapping 
> step to every one of these calls. For me, getting a random number and picking 
> a random element of a collection are two different operations—where it’s 
> common to work with empty collections, especially in generic code, trying to 
> get a random value from an empty range is really a programming error. I think 
> it’s okay for them to have slightly different semantics.
> 
> Nate
> 
> 
>> On Oct 5, 2017, at 12:27 PM, Alejandro Alonso > > wrote:
>> 
>> Rather 0 ..< 0 my bad. I think if we include closedcountable, then there 
>> needs to be support for countable, but there are edge cases where users can 
>> input invalid ranges for countable. 
>> 
>> Enviado desde mi iPhone
>> 
>> El oct. 5, 2017, a la(s) 12:22, Alejandro Alonso via swift-evolution 
>> > escribió:
>> 
>>> I agree with Ben here because users can still enter an invalid range with 
>>> the static function. I.E. Int.random(in: 0 ... 0). 
>>> I would really prefer excluding these static functions from numeric types.
>>> 
>>> - Alejandro
>>> 
>>> El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution 
>>> > escribió:
>>> 
> On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution 
> > wrote:
> 
>> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>> ```
>>> extension Int {
>>>   static func random(in range: Countable{Closed}Range) -> Int
>>> }
>> 
>> Nice.  Should these be initializers like:
>> 
>> extension Int {
>>   init(randomIn: Countable{Closed}Range)
>> }
>> 
> 
> I don’t see much of a case for making it it random(in: 
> SpecificCollection) instead of genericCollection.random().
 
 I see a couple points in favor of these static methods (or initializers) 
 on the numeric types:
 
 1) The collection method will need to return an optional to match the 
 semantics of existing methods (like min()). If this is the only method 
 available, every time someone needs a random value in the range 1...10, 
 they’ll need to unwrap the result (with either force unwrapping, which 
 people will complain about, or some kind of conditional binding, which is 
 its own problem). Even if the semantics are the same (trapping on an empty 
 range), the user experience of using a non-optional method will be better.
 
 2) Floating-point ranges won’t get the collection method, so either we’ll 
 have inconsistent APIs (random FP value is non-optional, random integer is 
 optional) or we’ll make the FP API optional just to match. Both of those 
 seem bad.
 
> One possible reason is if you exclude half-open ranges, only having 
> CountableClosedRange, then you don’t have to account for the possibility 
> of an empty collection (via an optional or a trap) because they cannot be 
> empty. But closed ranges aren’t the currency type – half-open ranges are. 
> So it’d hit usability if you have to convert from one to t'other often.
> 
> Other possibility is discovery. But given the common use case is “random 
> element from collection”, I don’t expect this to be an issue as it will 
> quickly become common knowledge that this feature is available.
 
 Agreed here—I don’t think discovery is really an issue between the two 
 kinds. However, I 

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

[Joe Groff via swift-evolution]

> On Oct 5, 2017, at 10:46 AM, Taylor Swift  wrote:
> 
> why is runtime dispatch even necessary? Why can’t the client just call the 
> specialized version directly?

Runtime dispatch on the callee side keeps the exact set of specializations open 
to change, since it isn't ABI, and in theory shouldn't be all that expensive, 
since you're "just" checking type identity.

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

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

[Nate Cook via swift-evolution]

The edge case is really the same (empty ranges), it’s about what we do with the 
edge case. If we include the methods on integer types, usage will look like 
this:

let x = Int.random(in: 0..<5) // 3
let y = Int.random(in: 0..<0) // runtime error

If we only have the collection methods, usage will look like this:

let x = (0..<5).random()! // 3
let y = (0..<0).random()! // runtime error

But my suspicion is that lots of people will write things like this:

guard let x = (0..<5).random() 
else { fatalError("not gonna happen") }

I’d rather have the numeric methods trap than add the optional unwrapping step 
to every one of these calls. For me, getting a random number and picking a 
random element of a collection are two different operations—where it’s common 
to work with empty collections, especially in generic code, trying to get a 
random value from an empty range is really a programming error. I think it’s 
okay for them to have slightly different semantics.

Nate


> On Oct 5, 2017, at 12:27 PM, Alejandro Alonso  wrote:
> 
> Rather 0 ..< 0 my bad. I think if we include closedcountable, then there 
> needs to be support for countable, but there are edge cases where users can 
> input invalid ranges for countable. 
> 
> Enviado desde mi iPhone
> 
> El oct. 5, 2017, a la(s) 12:22, Alejandro Alonso via swift-evolution 
> > escribió:
> 
>> I agree with Ben here because users can still enter an invalid range with 
>> the static function. I.E. Int.random(in: 0 ... 0). 
>> I would really prefer excluding these static functions from numeric types.
>> 
>> - Alejandro
>> 
>> El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution 
>> > escribió:
>> 
 On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution 
 > wrote:
 
> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> ```
>> extension Int {
>>   static func random(in range: Countable{Closed}Range) -> Int
>> }
> 
> Nice.  Should these be initializers like:
> 
> extension Int {
>   init(randomIn: Countable{Closed}Range)
> }
> 
 
 I don’t see much of a case for making it it random(in: SpecificCollection) 
 instead of genericCollection.random().
>>> 
>>> I see a couple points in favor of these static methods (or initializers) on 
>>> the numeric types:
>>> 
>>> 1) The collection method will need to return an optional to match the 
>>> semantics of existing methods (like min()). If this is the only method 
>>> available, every time someone needs a random value in the range 1...10, 
>>> they’ll need to unwrap the result (with either force unwrapping, which 
>>> people will complain about, or some kind of conditional binding, which is 
>>> its own problem). Even if the semantics are the same (trapping on an empty 
>>> range), the user experience of using a non-optional method will be better.
>>> 
>>> 2) Floating-point ranges won’t get the collection method, so either we’ll 
>>> have inconsistent APIs (random FP value is non-optional, random integer is 
>>> optional) or we’ll make the FP API optional just to match. Both of those 
>>> seem bad.
>>> 
 One possible reason is if you exclude half-open ranges, only having 
 CountableClosedRange, then you don’t have to account for the possibility 
 of an empty collection (via an optional or a trap) because they cannot be 
 empty. But closed ranges aren’t the currency type – half-open ranges are. 
 So it’d hit usability if you have to convert from one to t'other often.
 
 Other possibility is discovery. But given the common use case is “random 
 element from collection”, I don’t expect this to be an issue as it will 
 quickly become common knowledge that this feature is available.
>>> 
>>> Agreed here—I don’t think discovery is really an issue between the two 
>>> kinds. However, I don’t think the overlap in features (two ways to generate 
>>> random integers) are a problem, especially as we’d have better alignment 
>>> between integer and floating-point methods.
>>> 
>>> Nate
>>> ___
>>> 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] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Jose Cheyo Jimenez via swift-evolution]

> On Oct 5, 2017, at 4:32 AM, David Hart  wrote:
> 
>> 
>> On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution 
>> > wrote:
>> 
>> I appreciate the enthusiasm but this is not a bug. This was a deliberate 
>> change in swift 3 to make `private extension` usable. If this was a bug then 
>> during swift 3 we should have disallowed `private extension` and only 
>> allowed `fileprivate extension` but that is not what happened. `private 
>> extension` has worked the same since swift 1. I’ve always used `private 
>> extension` when I want to add methods to String or other build in types. 
> 
> It’s not a bug, but its unfortunate the behaviour wasn’t changed at the same 
> time as SE-0169, and it now is very inconsistent. I also don’t have to rehash 
> previous discussions, but if a Core Team member (Chris) is okay with going 
> ahead with this, perhaps we should consider it.

This could have not been part of 169 because it would've required to lower the 
visibility of the private extension modifier.

“No migration will be necessary as this proposal merely broadens the visibility 
of private.”

There was a corner case mentioned when dealing with functions with the same 
name and that was understandable. 

private extension is consistent to the way the private scope rules work. The 
word private is explicit at the top level because extensions can only be 
declared at top level. Top level private is always fileprivate. The 
inconsistency is that we have 1 scope ALC and the rest are not. An explicit 
declaration should always take precedence when declaring something like an 
access level override.

> 
>> private is different because it is scoped so because of that it is also 
>> different when dealing with extensions. Top level private is always the same 
>> as fileprivate thanks to its scoped nature. 
>> 
>> Making private the scope ACL was a mistake but that ship has sailed and so 
>> has this one imo. 
>> 
>> 
>> 
>> On Oct 4, 2017, at 10:05 PM, Tony Allevato > > wrote:
>> 
>>> Trust me, I'm the last person who wants to rehash access levels in Swift 
>>> again. But that's not what's happening here, IMO, and fixing bugs is not 
>>> just "a change for the sake of changing."
>>> 
>>> The current behavior of "private extension" is *incorrect*, because it's 
>>> entirely inconsistent with how access levels on extensions are documented 
>>> to behave and it's inconsistent with how other access levels apply to 
>>> extensions.
>>> 
>>> Can anyone think of a reason—other than "it's too late to change it"—why 
>>> "private extension" and "fileprivate extension" should behave the same, and 
>>> why "X extension { decl }" should be identical to "extension { X decl }" 
>>> for all X *except* "private"?
>>> 
>>> Yes, it's absolutely unfortunate that this oversight was not addressed when 
>>> the other access level changes were made. But we shouldn't have to live 
>>> with bugs in the language because we're afraid of some unknown amount of 
>>> churn among code that is already written incorrectly. Nor is fixing this 
>>> bug declaring open season on other, unrelated access level debates. Do you 
>>> have data that shows that the amount of code broken because it's using 
>>> "private" when it really should be saying "fileprivate" is high enough that 
>>> we should just leave the bug there?
>>> 
>>> On Wed, Oct 4, 2017 at 9:51 PM Jose Cheyo Jimenez via swift-evolution 
>>> > wrote:
>>> There was a high bar for breaking changes in swift 4 and is even higher for 
>>> swift 5.  se-110 was approved and implemented on the premises that it was 
>>> not a big change but it was breaking code so it got reverted. Sure the 
>>> migrator was making this easier but the result was a usability regression. 
>>> I think this is a change just for the sake of changing. This will cause 
>>> unnecessary churn. Let’s leave ACLs alone for the next few versions of 
>>> swift unless we have a way better system. 
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html
>>>  
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Oct 4, 2017, at 8:47 PM, BJ Homer >> > wrote:
>>> 
 It certainly could break *some* code. But it only breaks code written by 
 an author who wrote ‘private extension’ knowing that ‘fileprivate 
 extension’ was also an option, but still intended it to be shared with the 
 whole file. (If that code was from Swift 2, it would have already been 
 migrated to ‘fileprivate extension’ by the 2->3 migrator.)
 
 So existing code that says ‘private extension’ was written in a Swift 3 or 
 4 era when ‘fileprivate’ was an option. If the goal was specifically 

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

[Taylor Swift via swift-evolution]

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

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

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

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

[Alejandro Alonso via swift-evolution]

Rather 0 ..< 0 my bad. I think if we include closedcountable, then there needs 
to be support for countable, but there are edge cases where users can input 
invalid ranges for countable.

Enviado desde mi iPhone

El oct. 5, 2017, a la(s) 12:22, Alejandro Alonso via swift-evolution 
> escribió:

I agree with Ben here because users can still enter an invalid range with the 
static function. I.E. Int.random(in: 0 ... 0).
I would really prefer excluding these static functions from numeric types.

- Alejandro

El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution 
> escribió:

On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution 
> wrote:

On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution 
> wrote:

```
extension Int {
  static func random(in range: Countable{Closed}Range) -> Int
}

Nice.  Should these be initializers like:

extension Int {
  init(randomIn: Countable{Closed}Range)
}


I don’t see much of a case for making it it random(in: SpecificCollection) 
instead of genericCollection.random().

I see a couple points in favor of these static methods (or initializers) on the 
numeric types:

1) The collection method will need to return an optional to match the semantics 
of existing methods (like min()). If this is the only method available, every 
time someone needs a random value in the range 1...10, they’ll need to unwrap 
the result (with either force unwrapping, which people will complain about, or 
some kind of conditional binding, which is its own problem). Even if the 
semantics are the same (trapping on an empty range), the user experience of 
using a non-optional method will be better.

2) Floating-point ranges won’t get the collection method, so either we’ll have 
inconsistent APIs (random FP value is non-optional, random integer is optional) 
or we’ll make the FP API optional just to match. Both of those seem bad.

One possible reason is if you exclude half-open ranges, only having 
CountableClosedRange, then you don’t have to account for the possibility of an 
empty collection (via an optional or a trap) because they cannot be empty. But 
closed ranges aren’t the currency type – half-open ranges are. So it’d hit 
usability if you have to convert from one to t'other often.

Other possibility is discovery. But given the common use case is “random 
element from collection”, I don’t expect this to be an issue as it will quickly 
become common knowledge that this feature is available.

Agreed here—I don’t think discovery is really an issue between the two kinds. 
However, I don’t think the overlap in features (two ways to generate random 
integers) are a problem, especially as we’d have better alignment between 
integer and floating-point methods.

Nate
___
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

[Alejandro Alonso via swift-evolution]

I agree with Ben here because users can still enter an invalid range with the 
static function. I.E. Int.random(in: 0 ... 0).
I would really prefer excluding these static functions from numeric types.

- Alejandro

El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution 
> escribió:

On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution 
> wrote:

On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution 
> wrote:

```
extension Int {
  static func random(in range: Countable{Closed}Range) -> Int
}

Nice.  Should these be initializers like:

extension Int {
  init(randomIn: Countable{Closed}Range)
}


I don’t see much of a case for making it it random(in: SpecificCollection) 
instead of genericCollection.random().

I see a couple points in favor of these static methods (or initializers) on the 
numeric types:

1) The collection method will need to return an optional to match the semantics 
of existing methods (like min()). If this is the only method available, every 
time someone needs a random value in the range 1...10, they’ll need to unwrap 
the result (with either force unwrapping, which people will complain about, or 
some kind of conditional binding, which is its own problem). Even if the 
semantics are the same (trapping on an empty range), the user experience of 
using a non-optional method will be better.

2) Floating-point ranges won’t get the collection method, so either we’ll have 
inconsistent APIs (random FP value is non-optional, random integer is optional) 
or we’ll make the FP API optional just to match. Both of those seem bad.

One possible reason is if you exclude half-open ranges, only having 
CountableClosedRange, then you don’t have to account for the possibility of an 
empty collection (via an optional or a trap) because they cannot be empty. But 
closed ranges aren’t the currency type – half-open ranges are. So it’d hit 
usability if you have to convert from one to t'other often.

Other possibility is discovery. But given the common use case is “random 
element from collection”, I don’t expect this to be an issue as it will quickly 
become common knowledge that this feature is available.

Agreed here—I don’t think discovery is really an issue between the two kinds. 
However, I don’t think the overlap in features (two ways to generate random 
integers) are a problem, especially as we’d have better alignment between 
integer and floating-point methods.

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

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

[Ben Langmuir via swift-evolution]

Hi Slava,

What is the impact on debugging?  Will we emit a non-inline version of the 
function into the client at Onone? Will it be impossible to call from a 
debugger with optimization enabled?  I've been burned by this in C++.

Ben

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

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

[Nate Cook via swift-evolution]

> On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution 
>  wrote:
> 
>> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>> ```
>>> extension Int {
>>>   static func random(in range: Countable{Closed}Range) -> Int
>>> }
>> 
>> Nice.  Should these be initializers like:
>> 
>> extension Int {
>>   init(randomIn: Countable{Closed}Range)
>> }
>> 
> 
> I don’t see much of a case for making it it random(in: SpecificCollection) 
> instead of genericCollection.random().

I see a couple points in favor of these static methods (or initializers) on the 
numeric types:

1) The collection method will need to return an optional to match the semantics 
of existing methods (like min()). If this is the only method available, every 
time someone needs a random value in the range 1...10, they’ll need to unwrap 
the result (with either force unwrapping, which people will complain about, or 
some kind of conditional binding, which is its own problem). Even if the 
semantics are the same (trapping on an empty range), the user experience of 
using a non-optional method will be better.

2) Floating-point ranges won’t get the collection method, so either we’ll have 
inconsistent APIs (random FP value is non-optional, random integer is optional) 
or we’ll make the FP API optional just to match. Both of those seem bad.

> One possible reason is if you exclude half-open ranges, only having 
> CountableClosedRange, then you don’t have to account for the possibility of 
> an empty collection (via an optional or a trap) because they cannot be empty. 
> But closed ranges aren’t the currency type – half-open ranges are. So it’d 
> hit usability if you have to convert from one to t'other often.
> 
> Other possibility is discovery. But given the common use case is “random 
> element from collection”, I don’t expect this to be an issue as it will 
> quickly become common knowledge that this feature is available.

Agreed here—I don’t think discovery is really an issue between the two kinds. 
However, I don’t think the overlap in features (two ways to generate random 
integers) are a problem, especially as we’d have better alignment between 
integer and floating-point methods.

Nate___
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

[Joe Groff via swift-evolution]

> On Oct 4, 2017, at 9:15 PM, Chris Lattner  wrote:
> 
> 
>> On Oct 4, 2017, at 9:36 AM, Joe Groff > > wrote:
>> 
> It wouldn't avoid the complexity, because we want the "non-ABI, 
> always-emit-into-client" behavior for the standard library. For the 
> soon-to-be-ABI-stable libraries where @inlinable even matters, such as 
> the standard library and Apple SDK overlays, there's pretty much perfect 
> overlap between things we want to inline and things we don't want to take 
> up binary space and ABI surface in binaries, so the behavior Slava 
> proposes seems like the right default. 
 
 I disagree.  The semantics being proposed perfectly overlap with the 
 transitional plan for overlays (which matters for the next few years), but 
 they are the wrong default for anything other than overlays and the wrong 
 thing for long term API evolution over the next 20 years.
>>> 
>>> Can you elaborate on this? If inlinable functions have public entry points, 
>>> the version in the framework may or may not be called… because of SIL 
>>> serialization and inlining. Since the existence of the public entry point 
>>> doesn’t offer much of a guarantee, it seems desirable to not have the 
>>> public entry point. For example if the inlinable function is not used 
>>> elsewhere in the framework, we wouldn’t have to emit it at all. This might 
>>> make the standard library smaller for instance.
>>> 
>>> However I’m still waiting for Dave or Jordan to chime in with the original 
>>> justification for the ‘always emit into client’ behavior. IIRC there was a 
>>> resilience-related argument too, but I don’t remember what it is now.
>> 
>> The suggestion to have this semantics was originally my fault, I believe, 
>> and it arose from the observation that if we have 'inlinable' backed by a 
>> symbol in the binary, then we'd also want the 'must be emitted by client' 
>> attribute. I think 'must be emitted by client' is going to almost always be 
>> preferable for an inlinable function, though, so it's better to have the 
>> single attribute with this behavior, only constrained by backward deployment.
> 
> What is the use case of “must be emitted by client” attribute?  If I imagine 
> that the Swift 5 standard library is shipped in the OS, I can see cases where 
> deprecated/legacy shims for Swift3/4 compatibility would be emitted into the 
> client but not shipped in the OS.  Those seem relatively obscure though.

You could just as easily pose the opposite question—what's the use case for a 
symbol in the dylib when the definition is visible to clients? Evaluating the 
tradeoffs, we feel like it's better not to unless backward compatibility 
demands it.

-Joe

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

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

[Ben Cohen via swift-evolution]

> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> ```
>> extension Int {
>>   static func random(in range: Countable{Closed}Range) -> Int
>> }
> 
> Nice.  Should these be initializers like:
> 
> extension Int {
>   init(randomIn: Countable{Closed}Range)
> }
> 

I don’t see much of a case for making it it random(in: SpecificCollection) 
instead of genericCollection.random().

One possible reason is if you exclude half-open ranges, only having 
CountableClosedRange, then you don’t have to account for the possibility of an 
empty collection (via an optional or a trap) because they cannot be empty. But 
closed ranges aren’t the currency type – half-open ranges are. So it’d hit 
usability if you have to convert from one to t'other often.

Other possibility is discovery. But given the common use case is “random 
element from collection”, I don’t expect this to be an issue as it will quickly 
become common knowledge that this feature is available.


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

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

[Félix Cloutier via swift-evolution]

> Le 4 oct. 2017 à 19:26, Xiaodi Wu via swift-evolution 
>  a écrit :
> To sum up my thoughts so far in code, building on previous comments from 
> others, this would be a nice set of random APIs, IMO:
> 
> ```
> extension Int {
>   static func random(in range: Countable{Closed}Range) -> Int
> }
> // And similar for other concrete built-in integer types.
> //
> // Since fixed-width integers could exceed the maximum size supported by 
> getrandom()
> // and other such functions, we do not provide a default implementation.
> //
> // The return value may not be cryptographically secure if there is 
> insufficient entropy.

I don't think that we should limit implementations based on that. If it's not 
an issue for `random(byteCount:)`, then it shouldn't be an issue for 
FixedWidthInteger.

(Also, I know that getrandom has a threshold where it becomes interruptible, 
but I'm not aware of an actual maximum size.)

> 
> extension Float {
>   static func random(in range: {Closed}Range) -> Float
> }
> 
> extension Double {
>   static func random(in range: {Closed}Range) -> Double
> }
> 
> extension Float80 {
>   // Ditto.
> }
> 
> extension Data {
>   static func random(byteCount: Int) -> Data
> }
> 
> extension UnsafeMutableRawPointer {
>   func copyRandomBytes(count: Int) throws
> }
> // This function is to be the most primitive of the random APIs, and will 
> throw if there is insufficient entropy.
> 
> extension UnsafeMutableRawBufferPointer {
>   func copyRandomBytes() throws
> }
> // Just as UMRBP.copyBytes(from:) parallels UMRP.copyBytes(from:count:), we 
> offer this convenience here.

What happened to the collection-based random functions? I'm not incredibly 
attached to them, but it doesn't seem to me that anyone has explicitly willed 
them away and I just want to be sure that it's not an oversight.

Félix

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

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

[Nevin Brackett-Rozinsky via swift-evolution]

On Tue, Oct 3, 2017 at 2:02 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> You want:
>
> x²  to parse as “superscript2(x)” - not as an identifier “xsuperscript2”
> which is distinct from x.
>
> -Chris


I am of two minds on this. Sometimes I want x² to parse as x*x (an
operator) but other times I want to store the value of x*x in an identifier
spelled… x². This could be simply to avoid repeatedly performing the same
calculation, or it could be the natural result as in,

let r² = someStatisticsThing(xVals, yVals)

Not sure where I’m going with this, just wanted to mention it.

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[David Hart via swift-evolution]

> On 5 Oct 2017, at 07:34, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> I appreciate the enthusiasm but this is not a bug. This was a deliberate 
> change in swift 3 to make `private extension` usable. If this was a bug then 
> during swift 3 we should have disallowed `private extension` and only allowed 
> `fileprivate extension` but that is not what happened. `private extension` 
> has worked the same since swift 1. I’ve always used `private extension` when 
> I want to add methods to String or other build in types. 

It’s not a bug, but its unfortunate the behaviour wasn’t changed at the same 
time as SE-0169, and it now is very inconsistent. I also don’t have to rehash 
previous discussions, but if a Core Team member (Chris) is okay with going 
ahead with this, perhaps we should consider it.

> private is different because it is scoped so because of that it is also 
> different when dealing with extensions. Top level private is always the same 
> as fileprivate thanks to its scoped nature. 
> 
> Making private the scope ACL was a mistake but that ship has sailed and so 
> has this one imo. 
> 
> 
> 
> On Oct 4, 2017, at 10:05 PM, Tony Allevato  > wrote:
> 
>> Trust me, I'm the last person who wants to rehash access levels in Swift 
>> again. But that's not what's happening here, IMO, and fixing bugs is not 
>> just "a change for the sake of changing."
>> 
>> The current behavior of "private extension" is *incorrect*, because it's 
>> entirely inconsistent with how access levels on extensions are documented to 
>> behave and it's inconsistent with how other access levels apply to 
>> extensions.
>> 
>> Can anyone think of a reason—other than "it's too late to change it"—why 
>> "private extension" and "fileprivate extension" should behave the same, and 
>> why "X extension { decl }" should be identical to "extension { X decl }" for 
>> all X *except* "private"?
>> 
>> Yes, it's absolutely unfortunate that this oversight was not addressed when 
>> the other access level changes were made. But we shouldn't have to live with 
>> bugs in the language because we're afraid of some unknown amount of churn 
>> among code that is already written incorrectly. Nor is fixing this bug 
>> declaring open season on other, unrelated access level debates. Do you have 
>> data that shows that the amount of code broken because it's using "private" 
>> when it really should be saying "fileprivate" is high enough that we should 
>> just leave the bug there?
>> 
>> On Wed, Oct 4, 2017 at 9:51 PM Jose Cheyo Jimenez via swift-evolution 
>> > wrote:
>> There was a high bar for breaking changes in swift 4 and is even higher for 
>> swift 5.  se-110 was approved and implemented on the premises that it was 
>> not a big change but it was breaking code so it got reverted. Sure the 
>> migrator was making this easier but the result was a usability regression. I 
>> think this is a change just for the sake of changing. This will cause 
>> unnecessary churn. Let’s leave ACLs alone for the next few versions of swift 
>> unless we have a way better system. 
>> 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> On Oct 4, 2017, at 8:47 PM, BJ Homer > > wrote:
>> 
>>> It certainly could break *some* code. But it only breaks code written by an 
>>> author who wrote ‘private extension’ knowing that ‘fileprivate extension’ 
>>> was also an option, but still intended it to be shared with the whole file. 
>>> (If that code was from Swift 2, it would have already been migrated to 
>>> ‘fileprivate extension’ by the 2->3 migrator.)
>>> 
>>> So existing code that says ‘private extension’ was written in a Swift 3 or 
>>> 4 era when ‘fileprivate’ was an option. If the goal was specifically to 
>>> share it with the whole file, it seems likely that most authors would have 
>>> used ‘fileprivate extension’ instead of ‘private extension’, as that better 
>>> communicates the intention. Regardless, though, we could check against the 
>>> Swift source compatibility test suite to see how widespread that is.
>>> 
>>> Regardless, I think this change makes Swift a better language, and I’m in 
>>> favor of it.
>>> 
>>> -BJ
>>> 
>>> On Oct 4, 2017, at 9:10 PM, Jose Cheyo Jimenez via swift-evolution 
>>> > wrote:
>>> 
 
 
 On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution 
 > wrote:
 
> 
> 
> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> On Mon, Oct 2, 

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

[Dennis Ferguson via swift-evolution]

I concur with Taylor and John on this particular issue. As much as I use 
annotations in my daily work, I wouldn’t want the language cluttered up and 
there will always be industry unique annotations that would be frustratingly 
unsupported (e.g. I say “j” and you say “i”). 
dennis.

> On Oct 5, 2017, at 02:23 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Oct 5, 2017, at 2:31 AM, Taylor Swift via swift-evolution 
>> > wrote:
>> not to rain on anyone’s parade here but y’all are aware unicode superscripts 
>> don’t even form a complete alphabet right? This kind of syntax would really 
>> only work for positive integer literals and I don’t think making a wholesale 
>> change to the language like this is worth that.
> 
> I agree with this and would add only that making Swift code look like 
> idiomatic math notation is a huge problem and will probably never yield 
> satisfactory results.  Anyone who's really interested in this would probably 
> be much better off writing a source-to-source transformation that started 
> with the mathematical markup of their choice and just rewrote it as 
> idiomatically as possible.
> 
> John.
> 
>> 
>> On Thu, Oct 5, 2017 at 1:19 AM, Swift via swift-evolution 
>> > wrote:
>> Going a little further...
>> 
>> It’s not hard to imagine a situation where the order of a trailing 
>> annotation matters. Ie, that X²₃ is a different thing from X₃². (X squared 
>> sub 3 ≠ X sub 3 squared)
>> 
>> So i think you’d want an array of trailing annotations and an array of 
>> leading annotations, where an annotation is either a .superscript(U) or a 
>> .subscript(V). That way you’d be able to preserve the (potentially) relevant 
>> order. 
>> 
>> Dave
>> 
>> Sent from my iPhone
>> 
>> On Oct 5, 2017, at 12:04 AM, John Payne via swift-evolution 
>> > wrote:
>> 
>>> 
> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution 
> > wrote:
> 
> Chris Lattner wrote:
> 
>> Just FWIW, IMO, these make sense as operators specifically because they 
>> are commonly used by math people as operations that transform the thing 
>> they are attached to.  Superscript 2 is a function that squares its 
>> operand.  That said, perhaps there are other uses that I’m not aware of 
>> which get in the way of the utilitarian interpretation.
> 
> But there are SO MANY uses for superscripts, subscripts, and other such 
> annotations, and they are all context specific, just in math, without 
> getting into chemistry, physics, statistics, and so forth.
> 
> They’re really more like methods on the object to which they’re attached, 
> or the combination of a method and an argument.  
 
 I agree.
 
> Wouldn’t classing them as identifiers lend itself better to this?
 
 No, making them an operator is better for this usecase.
 
 You want:
 
 x²  to parse as “superscript2(x)” - not as an identifier “xsuperscript2” 
 which is distinct from x.
 
 -Chris
>>> 
>>> I’m not competent to evaluate the implications of that, but let me just 
>>> pass along what makes sense to me.  For all I know it may be a restatement 
>>> in different words, or a higher level view which your approach enables, or 
>>> I may just have no grasp at all of what’s involved.
>>> 
>>> For brevity I’ll refer to superscripts, subscripts, etc. as annotations.
>>> 
>>> An object may have more than one annotation, as with chemical elements 
>>> which are usually presented at least with both their atomic number and 
>>> atomic weight.  Moreover, in some circumstances it might not be possible to 
>>> evaluate the significance of any single annotation without taking one or 
>>> more others into account, so it might be important to present them 
>>> together, as in a struct or a collection.
>>> 
>>> Taking them singly, their significance is three part: 1) the type of the 
>>> object, 2) the position of the annotation, and 3) the value of the 
>>> annotation.
>>> 
>>> I would parse x² as x.trailingSuperscript(2), or better yet…
>>> 
>>> where X is the type of x, X.annotations would be a struct, similar to the 
>>> following
>>> 
>>> struct annotations {
>>> leadingSuperscript: T?
>>> leadingSubscript: U?
>>> triailingSuperscript: V?
>>> trailingSubscript: W?
>>> }
>>> 
>>> Taking this approach, x² would parse as x.annotations.trailingSuperscript = 
>>> 2, and would fail if X made no allowance for trailingSuperscripts.
>>> 
>>> Annotation values are frequently variables, xⁿ for example, and this is the 
>>> main reason it seems reasonable to me to class the value as anything 
>>> permitted by the type associated with an annotation in that position for 
>>> 

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

[John McCall via swift-evolution]

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

I agree with this and would add only that making Swift code look like idiomatic 
math notation is a huge problem and will probably never yield satisfactory 
results.  Anyone who's really interested in this would probably be much better 
off writing a source-to-source transformation that started with the 
mathematical markup of their choice and just rewrote it as idiomatically as 
possible.

John.

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

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

[Slava Pestov via swift-evolution]

Oh right. @_specialize modifies the original entry point to do runtime dispatch 
among the possible specializations. So the overhead comes from the unnecessary 
checks. I guess ideally we would have two versions of @_specialize, one adds 
the runtime dispatch whereas the other one just publishes static 
specializations which can be deserialized and used as needed.

Since @_specialize is not an officially supported attribute though, I would 
suggest punting this discussion until someone decides to push through an 
evolution proposal for it. For all intents and purposes, @inlinable is a 
superset of @_specialized because it defers the specialization decisions to the 
client.

Slava

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

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

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

[Taylor Swift via swift-evolution]

See the thread

from july over generic trig functions, where @_specialize() + @_inlineable
had a small but consistent performance penalty relative to @_inlineable
alone.

On Thu, Oct 5, 2017 at 1:32 AM, Slava Pestov  wrote:

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

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

[Slava Pestov via swift-evolution]

> On Oct 4, 2017, at 11:04 PM, Taylor Swift  wrote:
> 
> 
> 
> On Oct 5, 2017, at 12:52 AM, Slava Pestov  > wrote:
> 
>> 
>> 
>>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution 
>>> > wrote:
>>> 
>>> i’m just tryna follow along here && this is probably a dumb question, but 
>>> is it possible for a generic function to be emitted as a set of specialized 
>>> functions into the client, but not inlined everywhere? It can be the case 
>>> where a large generic function gets slowed down by the large number of 
>>> generic operations inside it but it doesn’t make sense for it to be inlined 
>>> completely.
>> 
>> This is already possible. The optimizer doesn’t have to inline an 
>> @_inlineable function at its call site; it can emit a call to a specialized 
>> version instead.
>> 
>> Slava
> 
> Is there a reason using @_specialize() and @_inlineable together is slower 
> than using @_inlineable by itself?

By specialization, I mean the optimizer pass which takes a function body and 
substitutes generic parameters with statically-known types.

I’m not sure what your question means though. Adding a @_specialize attribute 
should never make anything slower. Rather it makes the optimizer eagerly emit 
specializations of a function in the defining module. You can think of 
@_specialize and @inlinable as mostly mutually exclusive; either you publish 
the complete function body for clients to optimize as they please, or you 
publish a fixed set of specializations.

You might prefer the latter for secrecy (serialized SIL is much closer to 
source code than machine code), but the the former enables more general 
optimizations.

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

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

[Taylor Swift via swift-evolution]

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

On Thu, Oct 5, 2017 at 1:19 AM, Swift via swift-evolution <
swift-evolution@swift.org> wrote:

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

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

[Swift via swift-evolution]

Going a little further...

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

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

Dave

Sent from my iPhone

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

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

[John Payne via swift-evolution]

>> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution 
>> > wrote:
>> 
>> Chris Lattner wrote:
>> 
>>> Just FWIW, IMO, these make sense as operators specifically because they are 
>>> commonly used by math people as operations that transform the thing they 
>>> are attached to.  Superscript 2 is a function that squares its operand.  
>>> That said, perhaps there are other uses that I’m not aware of which get in 
>>> the way of the utilitarian interpretation.
>> 
>> But there are SO MANY uses for superscripts, subscripts, and other such 
>> annotations, and they are all context specific, just in math, without 
>> getting into chemistry, physics, statistics, and so forth.
>> 
>> They’re really more like methods on the object to which they’re attached, or 
>> the combination of a method and an argument.  
> 
> I agree.
> 
>> Wouldn’t classing them as identifiers lend itself better to this?
> 
> No, making them an operator is better for this usecase.
> 
> You want:
> 
> x²  to parse as “superscript2(x)” - not as an identifier “xsuperscript2” 
> which is distinct from x.
> 
> -Chris

I’m not competent to evaluate the implications of that, but let me just pass 
along what makes sense to me.  For all I know it may be a restatement in 
different words, or a higher level view which your approach enables, or I may 
just have no grasp at all of what’s involved.

For brevity I’ll refer to superscripts, subscripts, etc. as annotations.

An object may have more than one annotation, as with chemical elements which 
are usually presented at least with both their atomic number and atomic weight. 
 Moreover, in some circumstances it might not be possible to evaluate the 
significance of any single annotation without taking one or more others into 
account, so it might be important to present them together, as in a struct or a 
collection.

Taking them singly, their significance is three part: 1) the type of the 
object, 2) the position of the annotation, and 3) the value of the annotation.

I would parse x² as x.trailingSuperscript(2), or better yet…

where X is the type of x, X.annotations would be a struct, similar to the 
following

struct annotations {
leadingSuperscript: T?
leadingSubscript: U?
triailingSuperscript: V?
trailingSubscript: W?
}

Taking this approach, x² would parse as x.annotations.trailingSuperscript = 2, 
and would fail if X made no allowance for trailingSuperscripts.

Annotation values are frequently variables, xⁿ for example, and this is the 
main reason it seems reasonable to me to class the value as anything permitted 
by the type associated with an annotation in that position for the overall type 
in question.

I’ll read any replies with interest, but I don’t think I'll have anything more 
to say on this subject myself.

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

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

[Taylor Swift via swift-evolution]

> On Oct 5, 2017, at 12:52 AM, Slava Pestov  wrote:
> 
> 
> 
>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution 
>>  wrote:
>> 
>> i’m just tryna follow along here && this is probably a dumb question, but is 
>> it possible for a generic function to be emitted as a set of specialized 
>> functions into the client, but not inlined everywhere? It can be the case 
>> where a large generic function gets slowed down by the large number of 
>> generic operations inside it but it doesn’t make sense for it to be inlined 
>> completely.
> 
> This is already possible. The optimizer doesn’t have to inline an 
> @_inlineable function at its call site; it can emit a call to a specialized 
> version instead.
> 
> Slava

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

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

[Tony Allevato via swift-evolution]

Yes, you're right about the history of "private extension"—I was forgetting
some of the details of what transpired during those proposals. Thanks for
the reminder.

That being said, I would still argue that it would be a shame if we decided
that the language should propagate a known inconsistency indefinitely
simply because it was overlooked during a proposal that could have fixed
it. I'd weigh the reduction of future user confusion as more valuable than
the cost for existing code to do a one-time migration, but that might be
easy for me to say because I don't use access levels on extensions at all
in my own code so I don't have any skin in the game. :)


On Wed, Oct 4, 2017 at 10:33 PM Jose Cheyo Jimenez 
wrote:

> I appreciate the enthusiasm but this is not a bug. This was a deliberate
> change in swift 3 to make `private extension` usable. If this was a bug
> then during swift 3 we should have disallowed `private extension` and only
> allowed `fileprivate extension` but that is not what happened. `private
> extension` has worked the same since swift 1. I’ve always used `private
> extension` when I want to add methods to String or other build in types.
>
> private is different because it is scoped so because of that it is also
> different when dealing with extensions. Top level private is always the
> same as fileprivate thanks to its scoped nature.
>
> Making private the scope ACL was a mistake but that ship has sailed and so
> has this one imo.
>
>
>
> On Oct 4, 2017, at 10:05 PM, Tony Allevato 
> wrote:
>
> Trust me, I'm the last person who wants to rehash access levels in Swift
> again. But that's not what's happening here, IMO, and fixing bugs is not
> just "a change for the sake of changing."
>
> The current behavior of "private extension" is *incorrect*, because it's
> entirely inconsistent with how access levels on extensions are documented
> to behave and it's inconsistent with how other access levels apply to
> extensions.
>
> Can anyone think of a reason—other than "it's too late to change it"—why
> "private extension" and "fileprivate extension" should behave the same, and
> why "X extension { decl }" should be identical to "extension { X decl }"
> for all X *except* "private"?
>
> Yes, it's absolutely unfortunate that this oversight was not addressed
> when the other access level changes were made. But we shouldn't have to
> live with bugs in the language because we're afraid of some unknown amount
> of churn among code that is already written incorrectly. Nor is fixing this
> bug declaring open season on other, unrelated access level debates. Do you
> have data that shows that the amount of code broken because it's using
> "private" when it really should be saying "fileprivate" is high enough that
> we should just leave the bug there?
>
> On Wed, Oct 4, 2017 at 9:51 PM Jose Cheyo Jimenez via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> There was a high bar for breaking changes in swift 4 and is even higher
>> for swift 5.  se-110 was approved and implemented on the premises that it
>> was not a big change but it was breaking code so it got reverted. Sure the
>> migrator was making this easier but the result was a usability regression.
>> I think this is a change just for the sake of changing. This will cause
>> unnecessary churn. Let’s leave ACLs alone for the next few versions of
>> swift unless we have a way better system.
>>
>>
>> https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000386.html
>>
>>
>>
>>
>>
>>
>> On Oct 4, 2017, at 8:47 PM, BJ Homer  wrote:
>>
>> It certainly could break *some* code. But it only breaks code written by
>> an author who wrote ‘private extension’ knowing that ‘fileprivate
>> extension’ was also an option, but still intended it to be shared with the
>> whole file. (If that code was from Swift 2, it would have already been
>> migrated to ‘fileprivate extension’ by the 2->3 migrator.)
>>
>> So existing code that says ‘private extension’ was written in a Swift 3
>> or 4 era when ‘fileprivate’ was an option. If the goal was specifically to
>> share it with the whole file, it seems likely that most authors would have
>> used ‘fileprivate extension’ instead of ‘private extension’, as that better
>> communicates the intention. Regardless, though, we could check against the
>> Swift source compatibility test suite to see how widespread that is.
>>
>> Regardless, I think this change makes Swift a better language, and I’m in
>> favor of it.
>>
>> -BJ
>>
>> On Oct 4, 2017, at 9:10 PM, Jose Cheyo Jimenez via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> On Oct 2, 2017, at 9:59 PM, David Hart via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution <
>>