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

[Slava Pestov via swift-evolution]

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

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 
>>  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, 2017 at 9:16 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
  wrote:
 
 
 
> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 01.10.2017 1:18, Chris Lattner wrote:
>>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> Vladimir, I agree with you on that change, but it’s a separate 
>>> topic from this one.
>>> 
>>> 

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

[Tony Allevato via swift-evolution]

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 <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On 01.10.2017 1:18, Chris Lattner wrote:
>>
>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Vladimir, I agree with you on that change, but it’s a separate topic from
>> this one.
>>
>> Tony is absolutely correct that this topic has already been discussed. It
>> is a deliberate design decision that public types do not automatically
>> expose members without explicit access modifiers; this has been brought up
>> on this list, and it is clearly not in scope for discussion as no new
>> insight can arise this late in the game. The inconsistency with public
>> extensions was brought up, the proposed solution was to remove modifiers
>> for extensions, but this proposal was rejected. So, the final design is
>> what we have.
>>
>> Agreed.  The core team would only consider a refinement or change to
>> access control if there were something actively broken that mattered for
>> ABI stability.
>>
>>
>> So we have to live with *protected* extension inconsistency for very long
>> time just because core team don't want to even discuss _this particular_
>> inconsistency(when access level in *private extension* must be private, not
>> fileprivate)?
>>
>> Yes, we decided that access level for extension will mean a default and
>> top most access level for nested methods, OK. But even in this rule, which
>> already differ from access modifiers for types, we 

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

[Chris Lattner via swift-evolution]

> On Oct 4, 2017, at 9:40 PM, Taylor Swift  wrote:
> 
> 
> - It becomes an ABI compatibility liability that has to be preserved forever. 
> - It increases binary size for a function that's rarely used, and which is 
> often much larger as an outlined generic function than the simple operation 
> that can be inlined into client code. Inlining makes the most sense when the 
> inlined operation is smaller than a function call, so in many cases the net 
> dylib + executable size would increase.
> - It increases the uncertainty of the behavior client code sees. If an 
> inlinable function must always be emitted in the client, then client code 
> *always* gets the current definition. If an inlinable function calls into the 
> dylib when the compiler chooses not to inline it, then you may get the 
> current definition, or you may get an older definition from any published 
> version of the dylib. Ideally these all behave the same if the function is 
> inlinable, but quirks are going to be inevitable.
>  
> 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.

Yep, something like that would definitely be possible by a sufficiently smart 
compiler, it is compatible with both approaches.

-Chris

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

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, 2017 at 9:16 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> Sent from my iPad
> 
>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>>>  wrote:
>>> 
>>> On 01.10.2017 1:18, Chris Lattner wrote:
> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Vladimir, I agree with you on that change, but it’s a separate topic 
> from this one.
> 
> Tony is absolutely correct that this topic has already been 
> discussed. It is a deliberate design decision that public types do 
> not automatically expose members without explicit access modifiers; 
> this has been brought up on this list, and it is clearly not in scope 
> for discussion as no new insight can arise this late in the game. The 
> inconsistency with public extensions was brought up, the proposed 
> solution was to remove modifiers for extensions, but this proposal 
> was rejected. So, the final design is what we have.
 Agreed.  The core team would only consider a refinement or change to 
 access control if there were something actively broken that mattered 
 for ABI stability.
>>> 
>>> So we have to live with *protected* extension inconsistency for very 
>>> long time just because core team don't want to even discuss _this 
>>> particular_ inconsistency(when access level in *private extension* must 
>>> be private, not fileprivate)?
>>> 
>>> Yes, we decided that access level for extension will mean a default and 
>>> top most access level for nested methods, OK. But even in this rule, 
>>> which already differ from access modifiers for types, we have another 
>>> one special case for 'private extension'.
>>> 
>>> Don't you think this is not normal situation and actually there IMO 
>>> can't be any reason to keep this bug-producing inconsistency in Swift? 
>>> (especially given Swift 5 seems like is a last moment to fix this)
>> 
>> I hate to say it but I'm inclined to agree with Vladimir on this. 
>> "private extension" has a useful meaning now distinct from "fileprivate 
>> extension", and it was an oversight that SE-0169 didn't include a fix 
>> here. On this very narrow, very specific access control issue I think it 
>> would still be worth discussing; like Xiaodi said it's not related to 
>> James' original thread-starter.
> 
> I agree with this in principle but would not want to see it become a 
> slippery slope back into extremely long access control discussions.
> 
 
 As I've said elsewhere, I too agree with this in principle. I agree with 
 Jordan that the current state of things is justifiable but the 

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

[Taylor Swift via swift-evolution]

On Wed, Oct 4, 2017 at 11:44 AM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

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

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

[Riley Testut via swift-evolution]

Just as one small data point, I had no idea private extensions still applied 
fileprivate access to all members (I thought that had changed when SE-0169 was 
implemented). I’ve been using private extensions extensively because I thought 
they *did* apply private access to everything, not fileprivate.

Now knowing this isn’t the case, I can only imagine how many other people would 
be tripped up be this (especially people who haven’t followed Swift Evolution). 
I definitely think this inconsistency needs to be fixed.

> On Oct 4, 2017, at 8:48 PM, BJ Homer via swift-evolution 
>  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, 2017 at 9:16 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> Sent from my iPad
> 
>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>>>  wrote:
>>> 
>>> On 01.10.2017 1:18, Chris Lattner wrote:
> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Vladimir, I agree with you on that change, but it’s a separate topic 
> from this one.
> 
> Tony is absolutely correct that this topic has already been 
> discussed. It is a deliberate design decision that public types do 
> not automatically expose members without explicit access modifiers; 
> this has been brought up on this list, and it is clearly not in scope 
> for discussion as no new insight can arise this late in the game. The 
> inconsistency with public extensions was brought up, the proposed 
> solution was to remove modifiers for extensions, but this proposal 
> was rejected. So, the final design is what we have.
 Agreed.  The core team would only consider a refinement or change to 
 access control if there were something actively broken that mattered 
 for ABI stability.
>>> 
>>> So we have to live with *protected* extension inconsistency for very 
>>> long time just because core team don't want to even discuss _this 
>>> particular_ inconsistency(when access level in *private extension* must 
>>> be private, not fileprivate)?
>>> 
>>> Yes, we decided that access level for extension will mean a default and 
>>> top most access level for nested methods, OK. But even in this rule, 
>>> which already differ from access modifiers for types, we have another 
>>> one special case for 'private extension'.
>>> 
>>> Don't you think this is not normal situation and actually there IMO 
>>> can't be any reason to keep this bug-producing inconsistency in Swift? 
>>> (especially given Swift 5 seems like is a last moment to fix this)
>> 
>> I hate to say it but I'm inclined to agree with Vladimir on this. 
>> "private extension" has a useful meaning now distinct from "fileprivate 
>> extension", and it was an oversight that SE-0169 didn't include a fix 
>> here. On this very narrow, very specific access control issue I think it 
>> would still be worth discussing; like Xiaodi said it's not related to 
>> James' original thread-starter.
> 
> I agree with this in principle but would not want to see it become a 
> slippery slope back into extremely long access control discussions.
> 
 
 As I've said elsewhere, I too agree with this in principle. I agree with 
 Jordan that the current state of things is justifiable but the alternative 
 would be 

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

[Chris Lattner via swift-evolution]

> On Oct 4, 2017, at 9:24 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> 
>> - 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.

Also, not all inlinable functions are generic.  There are perfectly rationale 
reasons to inline non-generic functions as well, and they don’t benefit from 
the specialization benefits you’re indicating.

Finally, even if a symbol is generic, it isn’t certain that the client will be 
able to specialize.  The calls may be from unspecialized code after all.

-Chris

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

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

[Xiaodi Wu via swift-evolution]

Glibc random is not cryptographically secure, nor is it thread-safe.
getrandom() fails in more ways than arc4random and is therefore a primitive
on which we can base a shim but isn't suitable by itself. Swift used to use
libbsd internally on Linux but that dependency was removed. Currently, it
uses the C++ Mersenne twister engine on all platforms, which is not
cryptographically secure, with a device random seed that is not guaranteed
to be random by the C++ standard if no device is available. Likely,
therefore, a shim will have to be manually implemented.
On Wed, Oct 4, 2017 at 23:17 Alejandro Alonso via swift-evolution <
swift-evolution@swift.org> wrote:

> I think this is a good idea. I start asking questions about what our
> default generator for linux will be if we use Darwin’s arc4random(3). Do we
> use Glibc’s random()? If so, what do we seed it with?
>
> - Alejandro
>
> On Oct 4, 2017, 6:26 PM -0500, Ben Cohen via swift-evolution <
> swift-evolution@swift.org>, wrote:
>
>
>
> On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon 
> wrote:
>
> On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> - I’d love to see several of the most common random kinds supported, and I
> agree it would be nice (but not required IMO) for the default to be
> cryptographically secure.
>
>
> I would be very careful about choosing a "simple" solution. There is a
> log, sad history of languages trying to provide a "simple" random number
> generator and accidentally providing a powerful footgun instead. But:
>
> - We should avoid the temptation to nuke this mosquito with a heavy handed
> solution designed to solve all of the world’s problems: For example, the
> C++ random number stuff is crazily over-general.  The stdlib should aim to
> solve (e.g.) the top 3 most common cases, and let a more specialized
> external library solve the fully general problem (e.g. seed management,
> every distribution imaginable, etc).
>
>
> That's not to say we need to have seven engines and twenty distributions
> like C++ does. The standard library is not a statistics package; it exists
> to provide basic abstractions and fundamental functionality. I don't think
> it should worry itself with distributions at all. I think it needs to
> provide:
>
> 1. The abstraction used to plug in different random number generators
> (i.e. an RNG protocol of some kind).
>
> 2. APIs on existing standard library types which perform basic
> randomness-related functions correctly—essentially, encapsulating Knuth.
> (Specifically, I think selecting a random element from a collection (which
> also covers generating a random integer in a range), shuffling a mutable
> collection, and generating a random float will do the trick.)
>
> 3. A default RNG with a conservative design that will sometimes be too
> slow, but will never be insufficiently random.
>
> If you want to pick elements with a Poisson distribution, go get a
> statistics framework; if you want repeatable random numbers for testing,
> use a seedable PRNG from XCTest or some other test tools package. These can
> leverage the standard library's RNG protocol to work with existing random
> number generators or random number consumers.
>
>
> +1 to this general plan!
>
>
> This pretty much exactly matches my preferences.
>
> If random numbers go into the std lib, they should  being able to
> customize the source of randomness for speed or test reproducibility, but
> default to something sensible without the user having to know it’s
> configurable. On Darwin that default should be based on arc4random(3). The
> std lib doesn’t need to provide other non-default random sources.
> Non-random sources for testing should be part of test frameworks and plug
> in easily.
>
> The proposal should include shuffle and random element from collection,
> which are much-requested and not really the controversial part so won't
> hold up the overall progress of the proposal.
>
> (and no need for distributions other than uniform IMO,  or otherwise)
>
>
> -Chris
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
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

[Chris Lattner via swift-evolution]

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)?

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

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

-Chris

___
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 think this is a good idea. I start asking questions about what our default 
generator for linux will be if we use Darwin’s arc4random(3). Do we use Glibc’s 
random()? If so, what do we seed it with?

- Alejandro

On Oct 4, 2017, 6:26 PM -0500, Ben Cohen via swift-evolution 
, wrote:


On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution 
> wrote:


On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon 
> wrote:

On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution 
> wrote:

- I’d love to see several of the most common random kinds supported, and I 
agree it would be nice (but not required IMO) for the default to be 
cryptographically secure.

I would be very careful about choosing a "simple" solution. There is a log, sad 
history of languages trying to provide a "simple" random number generator and 
accidentally providing a powerful footgun instead. But:

- We should avoid the temptation to nuke this mosquito with a heavy handed 
solution designed to solve all of the world’s problems: For example, the C++ 
random number stuff is crazily over-general.  The stdlib should aim to solve 
(e.g.) the top 3 most common cases, and let a more specialized external library 
solve the fully general problem (e.g. seed management, every distribution 
imaginable, etc).

That's not to say we need to have seven engines and twenty distributions like 
C++ does. The standard library is not a statistics package; it exists to 
provide basic abstractions and fundamental functionality. I don't think it 
should worry itself with distributions at all. I think it needs to provide:

1. The abstraction used to plug in different random number generators (i.e. an 
RNG protocol of some kind).

2. APIs on existing standard library types which perform basic 
randomness-related functions correctly—essentially, encapsulating Knuth. 
(Specifically, I think selecting a random element from a collection (which also 
covers generating a random integer in a range), shuffling a mutable collection, 
and generating a random float will do the trick.)

3. A default RNG with a conservative design that will sometimes be too slow, 
but will never be insufficiently random.

If you want to pick elements with a Poisson distribution, go get a statistics 
framework; if you want repeatable random numbers for testing, use a seedable 
PRNG from XCTest or some other test tools package. These can leverage the 
standard library's RNG protocol to work with existing random number generators 
or random number consumers.

+1 to this general plan!

This pretty much exactly matches my preferences.

If random numbers go into the std lib, they should  being able to customize the 
source of randomness for speed or test reproducibility, but default to 
something sensible without the user having to know it’s configurable. On Darwin 
that default should be based on arc4random(3). The std lib doesn’t need to 
provide other non-default random sources. Non-random sources for testing should 
be part of test frameworks and plug in easily.

The proposal should include shuffle and random element from collection, which 
are much-requested and not really the controversial part so won't hold up the 
overall progress of the proposal.

(and no need for distributions other than uniform IMO,  or otherwise)


-Chris


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

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

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

[Chris Lattner via swift-evolution]

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

The other issue is that if/when the stdlib and overlays start shipping in the 
OS, that backward deployment will require them to be statically linked into the 
app (optionally with an arclite style dynamic fallback approach).  This problem 
seems orthogonal to the discussion though.

-Chris

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

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

[Chris Lattner via swift-evolution]

On Oct 4, 2017, at 7:26 PM, Xiaodi Wu via swift-evolution 
 wrote:
> * Remove the range-less function. Naive users often write things like 
> `Int.random() % 100`, which unbeknownst to them is biased. Providing only the 
> ranged interface nudges naive users toward correct usage. 
> 
> * Provide an "easy" way to get some random bytes instead of a random number. 
> Perhaps a Data initializer that returns random-filled bytes of the requested 
> length. This helps make up for the lack of a range-less function on 
> FixedWidthInteger.
> 
> The "easy" functions should get the best names: Int.random(in:), 
> Data.random(length:), etc. The fundamental CSPRNG interface should have an 
> interface that is less friendly and less discoverable.
> 
> Agree, this is a very tractable set of functions for an initial 
> implementation. In fact, with these primitives and maybe some shuffling and 
> choosing conveniences in the stdlib, I see the remainder as useful-to-haves 
> that may or may not be critical for inclusion in the stdlib vs more 
> appropriate for a dedicated math library (more to follow on that thought in a 
> little while).
> 
> 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
> }

Nice.  Should these be initializers like:

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

or some other spelling?

> extension Data {
>   static func random(byteCount: Int) -> Data
> }

Similarly:

extension Data {
  init(randomByteCount: Int)
}


> 
> 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.
> ```

I’m not sure what the semantics of these APIs are, but with the appropriate doc 
comment they’re probably great :-)

-Chris


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

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

[Chris Lattner via swift-evolution]

> On Oct 4, 2017, at 7:07 PM, Xiaodi Wu  wrote:
> 
> On Wed, Oct 4, 2017 at 20:32 Chris Lattner  > wrote:
> FWIW, I agree with Ben here: if the true cryptographically secure random 
> numbers force this complexity onto users, then we should settle for something 
> close but not quite that bulletproof.
> 
> As long as it's a conscious design choice, that's potentially fine. My 
> purpose in raising this issue is to point out that there is a choice to be 
> made. Another consideration is that, if primitives such as Int.random() 
> silently degrade, they cannot be the basis upon which more sophisticated 
> secure APIs are built.

Understood - and please keep in mind that I am not a random number expert. :-)

I think that the default Int.random() sorts of functions should provide an 
abstraction that never fails.  Forcing failure onto clients will cause more 
bugs than it will prevent IMO (and it sounds like Ben is aligned on that as 
well).  I suspect that folks who truly need verifiably cryptographically secure 
RNG’s will also have other requirements which would lead to them not wanting to 
use a “Int.random()” style interface anyway, so it is fine to push that 
complexity down to the more power-user API.

-Chris


___
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")

[BJ Homer via swift-evolution]

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, 2017 at 9:16 PM, Matthew Johnson via swift-evolution 
  wrote:
 
 
 Sent from my iPad
 
> On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>>  wrote:
>> 
>> On 01.10.2017 1:18, Chris Lattner wrote:
 On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
  wrote:
 
 Vladimir, I agree with you on that change, but it’s a separate topic 
 from this one.
 
 Tony is absolutely correct that this topic has already been discussed. 
 It is a deliberate design decision that public types do not 
 automatically expose members without explicit access modifiers; this 
 has been brought up on this list, and it is clearly not in scope for 
 discussion as no new insight can arise this late in the game. The 
 inconsistency with public extensions was brought up, the proposed 
 solution was to remove modifiers for extensions, but this proposal was 
 rejected. So, the final design is what we have.
>>> Agreed.  The core team would only consider a refinement or change to 
>>> access control if there were something actively broken that mattered 
>>> for ABI stability.
>> 
>> So we have to live with *protected* extension inconsistency for very 
>> long time just because core team don't want to even discuss _this 
>> particular_ inconsistency(when access level in *private extension* must 
>> be private, not fileprivate)?
>> 
>> Yes, we decided that access level for extension will mean a default and 
>> top most access level for nested methods, OK. But even in this rule, 
>> which already differ from access modifiers for types, we have another 
>> one special case for 'private extension'.
>> 
>> Don't you think this is not normal situation and actually there IMO 
>> can't be any reason to keep this bug-producing inconsistency in Swift? 
>> (especially given Swift 5 seems like is a last moment to fix this)
> 
> I hate to say it but I'm inclined to agree with Vladimir on this. 
> "private extension" has a useful meaning now distinct from "fileprivate 
> extension", and it was an oversight that SE-0169 didn't include a fix 
> here. On this very narrow, very specific access control issue I think it 
> would still be worth discussing; like Xiaodi said it's not related to 
> James' original thread-starter.
 
 I agree with this in principle but would not want to see it become a 
 slippery slope back into extremely long access control discussions.
 
>>> 
>>> As I've said elsewhere, I too agree with this in principle. I agree with 
>>> Jordan that the current state of things is justifiable but the alternative 
>>> would be somewhat superior, agree that in a vacuum this very narrow and 
>>> specific discussion might be warranted, and agree also that this could be a 
>>> very slippery slide down a very steep slope.
>> 
>> Same here. It’s the only grudge I have left with the current access control 
>> situation. I remember Doug Gregor and John McCall discussing this during the 
>> last access control proposal. And I wouldn’t mind having a very narrow 
>> discussion about only this.
>> 
>> I organize my types into extensions for each conformance and for each access 
>> control. I can currently implicitly apply public or fileprivate to all 
>> members of an extension but I have no way of doing the same for private. 
>> That’s why I think it should be 

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

[Jose Cheyo Jimenez via swift-evolution]

> 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, 2017 at 9:16 PM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution 
  wrote:
 
 
 
> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 01.10.2017 1:18, Chris Lattner wrote:
>>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> Vladimir, I agree with you on that change, but it’s a separate topic 
>>> from this one.
>>> 
>>> Tony is absolutely correct that this topic has already been discussed. 
>>> It is a deliberate design decision that public types do not 
>>> automatically expose members without explicit access modifiers; this 
>>> has been brought up on this list, and it is clearly not in scope for 
>>> discussion as no new insight can arise this late in the game. The 
>>> inconsistency with public extensions was brought up, the proposed 
>>> solution was to remove modifiers for extensions, but this proposal was 
>>> rejected. So, the final design is what we have.
>> Agreed.  The core team would only consider a refinement or change to 
>> access control if there were something actively broken that mattered for 
>> ABI stability.
> 
> So we have to live with *protected* extension inconsistency for very long 
> time just because core team don't want to even discuss _this particular_ 
> inconsistency(when access level in *private extension* must be private, 
> not fileprivate)?
> 
> Yes, we decided that access level for extension will mean a default and 
> top most access level for nested methods, OK. But even in this rule, 
> which already differ from access modifiers for types, we have another one 
> special case for 'private extension'.
> 
> Don't you think this is not normal situation and actually there IMO can't 
> be any reason to keep this bug-producing inconsistency in Swift? 
> (especially given Swift 5 seems like is a last moment to fix this)
 
 I hate to say it but I'm inclined to agree with Vladimir on this. "private 
 extension" has a useful meaning now distinct from "fileprivate extension", 
 and it was an oversight that SE-0169 didn't include a fix here. On this 
 very narrow, very specific access control issue I think it would still be 
 worth discussing; like Xiaodi said it's not related to James' original 
 thread-starter.
>>> 
>>> I agree with this in principle but would not want to see it become a 
>>> slippery slope back into extremely long access control discussions.
>>> 
>> 
>> As I've said elsewhere, I too agree with this in principle. I agree with 
>> Jordan that the current state of things is justifiable but the alternative 
>> would be somewhat superior, agree that in a vacuum this very narrow and 
>> specific discussion might be warranted, and agree also that this could be a 
>> very slippery slide down a very steep slope.
> 
> Same here. It’s the only grudge I have left with the current access control 
> situation. I remember Doug Gregor and John McCall discussing this during the 
> last access control proposal. And I wouldn’t mind having a very narrow 
> discussion about only this.
> 
> I organize my types into extensions for each conformance and for each access 
> control. I can currently implicitly apply public or fileprivate to all 
> members of an extension but I have no way of doing the same for private. 
> That’s why I think it should be fixed.

This will break a bunch of code because `private extension` has always meant 
`fileprivate extension`. Even Swift 3 had this same behavior. Lowering the 
access level of the extension members will hide a bunch of code that was 
visible to the file. 

169 was not a breaking change but this “fix” would have made it a breaking 
change. I doubt 169 would had been accepted if it was a breaking change. I 
don’t think it’s worth it. 


https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md



> 
 
 (I maintain that the current model does not include a special case; it 
 simply means the 'private' is resolved at the level of the extension 
 rather than the level of its members. But that isn't what people expect 
 and it's not as useful.)
 
 
 I agree that changing the behavior of all access modifiers on extensions 
 is out of scope. (I also agree that it is a bad idea. Sorry, James, but 
 wanting 'pubic' here indicates that your mental model of 

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

[Xiaodi Wu via swift-evolution]

On Wed, Oct 4, 2017 at 21:01 Xiaodi Wu  wrote:

> On Wed, Oct 4, 2017 at 20:49 Greg Parker via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> On Oct 3, 2017, at 11:44 PM, Jonathan Hull via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I like the idea of splitting it into 2 separate “Random” proposals.
>>
>> The first would have Xiaodi’s built-in CSPRNG which only has the
>> interface:
>>
>> On FixedWidthInteger:
>> static func random()throws -> Self
>> static func random(in range: ClosedRange)throws -> Self
>>
>> On Double:
>> static func random()throws -> Double
>> static func random(in range: ClosedRange)throws -> Double
>>
>> (Everything else we want, like shuffled(), could be built in later
>> proposals by calling those functions)
>>
>> The other option would be to remove the ‘throws’ from the above functions
>> (perhaps fatalError-ing), and provide an additional function which can be
>> used to check that there is enough entropy (so as to avoid the crash or
>> fall back to a worse source when the CSPRNG is unavailable).
>>
>>
>> Then a second proposal would bring in the concept of RandomSources
>> (whatever we call them), which can return however many random bytes you ask
>> for… and a protocol for types which know how to initialize themselves from
>> those bytes.  That might be spelled like 'static func random(using:
>> RandomSource)->Self'.  As a convenience, the source would also be able to
>> create FixedWidthIntegers and Doubles (both with and without a range), and
>> would also have the coinFlip() and oneIn(UInt)->Bool functions. Most types
>> should be able to build themselves off of that.  There would be a default
>> source which is built from the first protocol.
>>
>> I also really think we should have a concept of Repeatably-Random as a
>> subprotocol for the second proposal.  I see far too many shipping apps
>> which have bugs due to using arc4Random when they really needed a
>> repeatable source (e.g. patterns and lines jump around when you resize
>> things). If it was an easy option, people would use it when appropriate.
>> This would just mean a sub-protocol which has an initializer which takes a
>> seed, and the ability to save/restore state (similar to CGContexts).
>>
>>
>> I like this kind of layering of functionality and proposals. I would
>> additionally separate the fundamental CSPRNG interface from the fool-proof
>> easy functions that naive users will find on Stack Overflow.
>>
>> The "easy" functions should:
>>
>> * Trap on any error without throwing. Sophisticated users may be able to
>> do something about entropy failure, so the fundamental CSPRNG interface
>> needs to provide errors, but the easy function should either degrade
>> somewhat (if entropy is present but insufficient) or just die (if entropy
>> is wholly absent or nearly so).
>>
>> * Remove the range-less function. Naive users often write things like
>> `Int.random() % 100`, which unbeknownst to them is biased. Providing only
>> the ranged interface nudges naive users toward correct usage.
>>
>> * Provide an "easy" way to get some random bytes instead of a random
>> number. Perhaps a Data initializer that returns random-filled bytes of the
>> requested length. This helps make up for the lack of a range-less function
>> on FixedWidthInteger.
>>
>> The "easy" functions should get the best names: Int.random(in:),
>> Data.random(length:), etc. The fundamental CSPRNG interface should have an
>> interface that is less friendly and less discoverable.
>>
>
> Agree, this is a very tractable set of functions for an initial
> implementation. In fact, with these primitives and maybe some shuffling and
> choosing conveniences in the stdlib, I see the remainder as useful-to-haves
> that may or may not be critical for inclusion in the stdlib vs more
> appropriate for a dedicated math library (more to follow on that thought in
> a little while).
>

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.

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
}

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

[Xiaodi Wu via swift-evolution]

On Wed, Oct 4, 2017 at 20:32 Chris Lattner  wrote:

> FWIW, I agree with Ben here: if the true cryptographically secure random
> numbers force this complexity onto users, then we should settle for
> something close but not quite that bulletproof.
>

As long as it's a conscious design choice, that's potentially fine. My
purpose in raising this issue is to point out that there is a choice to be
made. Another consideration is that, if primitives such as Int.random()
silently degrade, they cannot be the basis upon which more sophisticated
secure APIs are built.


On Oct 4, 2017, at 6:15 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Wed, Oct 4, 2017 at 18:42 Ben Cohen  wrote:
>
>>
>> On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> If trapping is OK, then surely returning Optional is superior; any user
>> who is OK with trapping can make that decision for themselves by writing
>> `random()!`. Everyone else can then see clearly that trapping is a
>> possibility, which is important.
>>
>>
>> It’s important not to underestimate both the extent to which using `!`
>> scares people, _and_ the extent to which beginners use it inappropriately.
>> Both of these mean that it’s very important the standard library not
>> include anything that makes force-unwrapping a common/routine operation
>> (looking at you, UnsafeBufferPointer.baseAddress).
>>
>
> I agree; however, if given the choice of `random()` potentially trapping
> or `random()!` potentially trapping, I would argue that the latter is
> strictly superior to the former. If the latter option scares people, the
> former should scare people more, and its nicer appearance is a bug, not a
> feature.
>
> Given that arc4random, the recommended source of random numbers on Darwin,
>> is always successful, requiring a force-unwrap when the user is using the
>> default source doesn’t seem like the right move.
>>
>
> Always successful for some values of successful. We cannot design our way
> out of physics.
>
> Chris has indicated—and I agree—that the default random facilities should
> do the right thing in terms of cryptographic security. Since arc4random is
> guaranteed to be successful but the underlying hardware cannot be
> guaranteed to always have the entropy to make it secure, it must follow
> that some invocations of arc4random produce results unsuitable for
> cryptographic use.
>
> To reiterate, this is one of several options. When there isn’t enough
> entropy for secure random numbers, the function can:
>
> - block
> - return an insecure result
> - return nil
> - throw
> - trap
>
> This is an exhaustive list, as far as I can tell. None of these options
> are entirely desirable, but it is inescapable that one of these is the
> default, go-to design for Swift; of course, alternatives can be offered,
> but the question is, what should we tell the novice user to reach for?
>
> On Wed, Oct 4, 2017 at 11:09 David Waite 
>> wrote:
>>
>>>
>>> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> I agree with Felix’s concern, which is why I brought up the question,
>>> but ultimately the issue is unavoidable. It’s not down to global instance
>>> or not. If your source of random numbers is unseedable and may mix in
>>> additional entropy at any time, then it may fail at any time because when a
>>> hardware restart might happen may be transparent to the process. The user
>>> must know about this or else we are laying a trap (pun intended).
>>>
>>>
>>> I'm of the mindset (which might be controversial) that we should attempt
>>> to expose legacy and cryptographically secure random number generators,
>>> even a mixed algorithmic/entropy source like /dev/urandom, but that we
>>> should not expose /dev/random at all. If someone is trying to use
>>> /dev/random legitimately (such as to generate one-time-pads) they will have
>>> to take into account that systems like linux still use algorithmic entropy
>>> to drive /dev/random. If someone really has this sort of use case, they
>>> have exceeded the bounds of the system randomness protocol.
>>>
>>> Without /dev/random support as a requirement, the only failure cases I
>>> know of are reading too much random data in one operation (which could be
>>> solved by repeated calls) or calling before sufficient entropy has been set
>>> up in /dev/urandom (such as in a system startup process). I'd be fine with
>>> the second one being a special case, and such systems needing to know use
>>> of the /dev/urandom -backed generator before randomness has been set up
>>> will trap or return predictable information on certain platforms.
>>>
>>> -DW
>>>
>> ___
>>
>>
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> 

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

[Xiaodi Wu via swift-evolution]

On Wed, Oct 4, 2017 at 20:49 Greg Parker via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 3, 2017, at 11:44 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I like the idea of splitting it into 2 separate “Random” proposals.
>
> The first would have Xiaodi’s built-in CSPRNG which only has the interface:
>
> On FixedWidthInteger:
> static func random()throws -> Self
> static func random(in range: ClosedRange)throws -> Self
>
> On Double:
> static func random()throws -> Double
> static func random(in range: ClosedRange)throws -> Double
>
> (Everything else we want, like shuffled(), could be built in later
> proposals by calling those functions)
>
> The other option would be to remove the ‘throws’ from the above functions
> (perhaps fatalError-ing), and provide an additional function which can be
> used to check that there is enough entropy (so as to avoid the crash or
> fall back to a worse source when the CSPRNG is unavailable).
>
>
> Then a second proposal would bring in the concept of RandomSources
> (whatever we call them), which can return however many random bytes you ask
> for… and a protocol for types which know how to initialize themselves from
> those bytes.  That might be spelled like 'static func random(using:
> RandomSource)->Self'.  As a convenience, the source would also be able to
> create FixedWidthIntegers and Doubles (both with and without a range), and
> would also have the coinFlip() and oneIn(UInt)->Bool functions. Most types
> should be able to build themselves off of that.  There would be a default
> source which is built from the first protocol.
>
> I also really think we should have a concept of Repeatably-Random as a
> subprotocol for the second proposal.  I see far too many shipping apps
> which have bugs due to using arc4Random when they really needed a
> repeatable source (e.g. patterns and lines jump around when you resize
> things). If it was an easy option, people would use it when appropriate.
> This would just mean a sub-protocol which has an initializer which takes a
> seed, and the ability to save/restore state (similar to CGContexts).
>
>
> I like this kind of layering of functionality and proposals. I would
> additionally separate the fundamental CSPRNG interface from the fool-proof
> easy functions that naive users will find on Stack Overflow.
>
> The "easy" functions should:
>
> * Trap on any error without throwing. Sophisticated users may be able to
> do something about entropy failure, so the fundamental CSPRNG interface
> needs to provide errors, but the easy function should either degrade
> somewhat (if entropy is present but insufficient) or just die (if entropy
> is wholly absent or nearly so).
>
> * Remove the range-less function. Naive users often write things like
> `Int.random() % 100`, which unbeknownst to them is biased. Providing only
> the ranged interface nudges naive users toward correct usage.
>
> * Provide an "easy" way to get some random bytes instead of a random
> number. Perhaps a Data initializer that returns random-filled bytes of the
> requested length. This helps make up for the lack of a range-less function
> on FixedWidthInteger.
>
> The "easy" functions should get the best names: Int.random(in:),
> Data.random(length:), etc. The fundamental CSPRNG interface should have an
> interface that is less friendly and less discoverable.
>

Agree, this is a very tractable set of functions for an initial
implementation. In fact, with these primitives and maybe some shuffling and
choosing conveniences in the stdlib, I see the remainder as useful-to-haves
that may or may not be critical for inclusion in the stdlib vs more
appropriate for a dedicated math library (more to follow on that thought in
a little while).


>
> --
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
> ___
> 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

[Greg Parker via swift-evolution]

> On Oct 3, 2017, at 11:44 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I like the idea of splitting it into 2 separate “Random” proposals.
> 
> The first would have Xiaodi’s built-in CSPRNG which only has the interface:
> 
> On FixedWidthInteger:
>   static func random()throws -> Self
>   static func random(in range: ClosedRange)throws -> Self
> 
> On Double:
>   static func random()throws -> Double
>   static func random(in range: ClosedRange)throws -> Double
> 
> (Everything else we want, like shuffled(), could be built in later proposals 
> by calling those functions)
> 
> The other option would be to remove the ‘throws’ from the above functions 
> (perhaps fatalError-ing), and provide an additional function which can be 
> used to check that there is enough entropy (so as to avoid the crash or fall 
> back to a worse source when the CSPRNG is unavailable).

> 

> Then a second proposal would bring in the concept of RandomSources (whatever 
> we call them), which can return however many random bytes you ask for… and a 
> protocol for types which know how to initialize themselves from those bytes.  
> That might be spelled like 'static func random(using: RandomSource)->Self'.  
> As a convenience, the source would also be able to create FixedWidthIntegers 
> and Doubles (both with and without a range), and would also have the 
> coinFlip() and oneIn(UInt)->Bool functions. Most types should be able to 
> build themselves off of that.  There would be a default source which is built 
> from the first protocol.
> 
> I also really think we should have a concept of Repeatably-Random as a 
> subprotocol for the second proposal.  I see far too many shipping apps which 
> have bugs due to using arc4Random when they really needed a repeatable source 
> (e.g. patterns and lines jump around when you resize things). If it was an 
> easy option, people would use it when appropriate. This would just mean a 
> sub-protocol which has an initializer which takes a seed, and the ability to 
> save/restore state (similar to CGContexts).


I like this kind of layering of functionality and proposals. I would 
additionally separate the fundamental CSPRNG interface from the fool-proof easy 
functions that naive users will find on Stack Overflow.

The "easy" functions should:

* Trap on any error without throwing. Sophisticated users may be able to do 
something about entropy failure, so the fundamental CSPRNG interface needs to 
provide errors, but the easy function should either degrade somewhat (if 
entropy is present but insufficient) or just die (if entropy is wholly absent 
or nearly so).

* Remove the range-less function. Naive users often write things like 
`Int.random() % 100`, which unbeknownst to them is biased. Providing only the 
ranged interface nudges naive users toward correct usage. 

* Provide an "easy" way to get some random bytes instead of a random number. 
Perhaps a Data initializer that returns random-filled bytes of the requested 
length. This helps make up for the lack of a range-less function on 
FixedWidthInteger.

The "easy" functions should get the best names: Int.random(in:), 
Data.random(length:), etc. The fundamental CSPRNG interface should have an 
interface that is less friendly and less discoverable.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

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

[Chris Lattner via swift-evolution]

FWIW, I agree with Ben here: if the true cryptographically secure random 
numbers force this complexity onto users, then we should settle for something 
close but not quite that bulletproof.

-Chris

> On Oct 4, 2017, at 6:15 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Wed, Oct 4, 2017 at 18:42 Ben Cohen  wrote:
>> 
>>> On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> If trapping is OK, then surely returning Optional is superior; any user who 
>>> is OK with trapping can make that decision for themselves by writing 
>>> `random()!`. Everyone else can then see clearly that trapping is a 
>>> possibility, which is important.
>> 
>> It’s important not to underestimate both the extent to which using `!` 
>> scares people, _and_ the extent to which beginners use it inappropriately. 
>> Both of these mean that it’s very important the standard library not include 
>> anything that makes force-unwrapping a common/routine operation (looking at 
>> you, UnsafeBufferPointer.baseAddress).
> 
> I agree; however, if given the choice of `random()` potentially trapping or 
> `random()!` potentially trapping, I would argue that the latter is strictly 
> superior to the former. If the latter option scares people, the former should 
> scare people more, and its nicer appearance is a bug, not a feature.
> 
>> Given that arc4random, the recommended source of random numbers on Darwin, 
>> is always successful, requiring a force-unwrap when the user is using the 
>> default source doesn’t seem like the right move.
> 
> Always successful for some values of successful. We cannot design our way out 
> of physics.
> 
> Chris has indicated—and I agree—that the default random facilities should do 
> the right thing in terms of cryptographic security. Since arc4random is 
> guaranteed to be successful but the underlying hardware cannot be guaranteed 
> to always have the entropy to make it secure, it must follow that some 
> invocations of arc4random produce results unsuitable for cryptographic use.
> 
> To reiterate, this is one of several options. When there isn’t enough entropy 
> for secure random numbers, the function can:
> 
> - block
> - return an insecure result
> - return nil
> - throw
> - trap
> 
> This is an exhaustive list, as far as I can tell. None of these options are 
> entirely desirable, but it is inescapable that one of these is the default, 
> go-to design for Swift; of course, alternatives can be offered, but the 
> question is, what should we tell the novice user to reach for?
> 
>> 
 On Wed, Oct 4, 2017 at 11:09 David Waite  
 wrote:
 
> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> I agree with Felix’s concern, which is why I brought up the question, but 
> ultimately the issue is unavoidable. It’s not down to global instance or 
> not. If your source of random numbers is unseedable and may mix in 
> additional entropy at any time, then it may fail at any time because when 
> a hardware restart might happen may be transparent to the process. The 
> user must know about this or else we are laying a trap (pun intended).
 
 I'm of the mindset (which might be controversial) that we should attempt 
 to expose legacy and cryptographically secure random number generators, 
 even a mixed algorithmic/entropy source like /dev/urandom, but that we 
 should not expose /dev/random at all. If someone is trying to use 
 /dev/random legitimately (such as to generate one-time-pads) they will 
 have to take into account that systems like linux still use algorithmic 
 entropy to drive /dev/random. If someone really has this sort of use case, 
 they have exceeded the bounds of the system randomness protocol.
 
 Without /dev/random support as a requirement, the only failure cases I 
 know of are reading too much random data in one operation (which could be 
 solved by repeated calls) or calling before sufficient entropy has been 
 set up in /dev/urandom (such as in a system startup process). I'd be fine 
 with the second one being a special case, and such systems needing to know 
 use of the /dev/urandom -backed generator before randomness has been set 
 up will trap or return predictable information on certain platforms.
 
 -DW
>> 
>>> ___
>> 
>>> 
>>> 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

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

[Xiaodi Wu via swift-evolution]

On Wed, Oct 4, 2017 at 18:42 Ben Cohen  wrote:

>
> On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If trapping is OK, then surely returning Optional is superior; any user
> who is OK with trapping can make that decision for themselves by writing
> `random()!`. Everyone else can then see clearly that trapping is a
> possibility, which is important.
>
>
> It’s important not to underestimate both the extent to which using `!`
> scares people, _and_ the extent to which beginners use it inappropriately.
> Both of these mean that it’s very important the standard library not
> include anything that makes force-unwrapping a common/routine operation
> (looking at you, UnsafeBufferPointer.baseAddress).
>

I agree; however, if given the choice of `random()` potentially trapping or
`random()!` potentially trapping, I would argue that the latter is strictly
superior to the former. If the latter option scares people, the former
should scare people more, and its nicer appearance is a bug, not a feature.

Given that arc4random, the recommended source of random numbers on Darwin,
> is always successful, requiring a force-unwrap when the user is using the
> default source doesn’t seem like the right move.
>

Always successful for some values of successful. We cannot design our way
out of physics.

Chris has indicated—and I agree—that the default random facilities should
do the right thing in terms of cryptographic security. Since arc4random is
guaranteed to be successful but the underlying hardware cannot be
guaranteed to always have the entropy to make it secure, it must follow
that some invocations of arc4random produce results unsuitable for
cryptographic use.

To reiterate, this is one of several options. When there isn’t enough
entropy for secure random numbers, the function can:

- block
- return an insecure result
- return nil
- throw
- trap

This is an exhaustive list, as far as I can tell. None of these options are
entirely desirable, but it is inescapable that one of these is the default,
go-to design for Swift; of course, alternatives can be offered, but the
question is, what should we tell the novice user to reach for?

On Wed, Oct 4, 2017 at 11:09 David Waite 
> wrote:
>
>>
>> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> I agree with Felix’s concern, which is why I brought up the question, but
>> ultimately the issue is unavoidable. It’s not down to global instance or
>> not. If your source of random numbers is unseedable and may mix in
>> additional entropy at any time, then it may fail at any time because when a
>> hardware restart might happen may be transparent to the process. The user
>> must know about this or else we are laying a trap (pun intended).
>>
>>
>> I'm of the mindset (which might be controversial) that we should attempt
>> to expose legacy and cryptographically secure random number generators,
>> even a mixed algorithmic/entropy source like /dev/urandom, but that we
>> should not expose /dev/random at all. If someone is trying to use
>> /dev/random legitimately (such as to generate one-time-pads) they will have
>> to take into account that systems like linux still use algorithmic entropy
>> to drive /dev/random. If someone really has this sort of use case, they
>> have exceeded the bounds of the system randomness protocol.
>>
>> Without /dev/random support as a requirement, the only failure cases I
>> know of are reading too much random data in one operation (which could be
>> solved by repeated calls) or calling before sufficient entropy has been set
>> up in /dev/urandom (such as in a system startup process). I'd be fine with
>> the second one being a special case, and such systems needing to know use
>> of the /dev/urandom -backed generator before randomness has been set up
>> will trap or return predictable information on certain platforms.
>>
>> -DW
>>
> ___
>
>
> 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] Resolving identifier vs. operator debates

[Ethan Tira-Thompson via swift-evolution]

Forking from discussion in “A path forward on rationalizing unicode identifiers 
and operators”, it was suggested to put this in a new thread.


Background:

Swift partitions the character set into operators and identifiers to aid in 
efficient parsing.  This has the unfortunate side effect that the language spec 
shoulders the burden of how to classify the thousands of unicode characters, 
and it must do so universally across all users and contexts.

There are many characters with ambiguous usage, such as denoting the transpose 
of matrix A as Aᵀ.  The notation is specifically using a superscript T, but 
this is also fundamentally a latin letter and the unicode code point is found 
in the phonetic extensions block, not the math symbols block.  In general, many 
symbols could refer either to an action (operator), or the result of that 
action (identifier), or have disparate domain-specific meanings.  Should the 
language spec really be in the business of deciding the ‘right’ use of each 
character like this?

I also assert a lot of the bad reputation of custom operators comes from 
languages which have limited operator character sets, which forces developers 
to overload standard operators with surprising effects, instead of choosing a 
symbol which is both unique and better recognized for the task at hand.  
Allowing developers to choose apt operator symbols is akin to encouraging 
descriptive identifiers.  Writing good code is all about making these choices 
appropriately, and that requires context, which only the end developer has.

To be clear, this will most likely be relegated to niche applications serving 
domain experts. As established below the default behavior is to opt-out of 
exotic operator choices.  But given a user who wishes to do so, better to give 
them the right tools for the purpose.


Goals:

1. Performance: file-local operator decisions (don’t require loading all the 
imports first)
2. Maintenance: improve operator auditing/discoverability
3. Functionality: let users write what they want without lobbying this list
4. Well defined: aid in resolving conflicts between modules


Pitch:

Enable users to ‘import' specific operator symbols on a per-file basis, 
updating the operator set used for parsing that file.

In the simplest form this would look like:
import operator ᵀ

This is only needed for “non-standard” operators.  But by providing this escape 
hatch, we can be conservative about choosing “standard” operators to a smaller, 
well known set and avoid a lot of debate without sacrificing expressibility.

When this import is encountered, then any matching operator declarations are 
made available simply because the character is interpreted as such.  (i.e. all 
modules’ operators are loaded as normal, but the compiler can only make the 
connection in files that opt-in to interpreting that character as an operator.) 
 Conversely, conflicting module identifiers become inaccessible following such 
an import, and hopefully good API would supply less exotic alternative 
interfaces for both cases.  Worst case the user could write an extension in a 
new file with the complementary character choice and remap offending 
operator/identifiers as they see fit.

Regarding operator declarations, one could suggest that the declaration itself 
could update the operator character set for that file.  However I suggest 
always requiring the import operator statement (for non-standard operators) 
partly to surface guidance when a choice of operator will require explicit 
imports from other files.  This also reduces potential for obfuscation by 
operators with visually similar representation, as the import list would draw 
attention to this chicanery.


Advanced Pitch:

The previous provides the “minimum viable product”, but we might like to take 
this a little further and make it module-specific:
import matrixlib (operators: [ᵀ,·,⊗])

Again, only “non-standard” operators need to be listed, the “standard” 
operators would import the same as today.  But now as readers we can see where 
special operators are coming from, and potentially filter competing 
declarations from different modules.  I also like that an operator family can 
be listed on a single line rather than potentially a dozen lines covering 
various combinations.  A module vendor can concisely document its operator list 
and make it easy to maintain and discover.

This syntax mimics a module “init” call, which could be a powerful concept for 
future extensions.  For example, we could introduce “standardOperators: false” 
to disable the automatic import of standard operators overloads—which some 
users might appreciate regardless of character set issues.  (e.g. users could 
select between conflicting standard operators in different modules, or just 
peace of mind there’s no surprises.)

I anticipate this form would take a bit more work to implement, as Swift would 
need to filter of the visibility of operators per module based on 

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

[Ben Cohen via swift-evolution]

> On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> If trapping is OK, then surely returning Optional is superior; any user who 
> is OK with trapping can make that decision for themselves by writing 
> `random()!`. Everyone else can then see clearly that trapping is a 
> possibility, which is important.

It’s important not to underestimate both the extent to which using `!` scares 
people, _and_ the extent to which beginners use it inappropriately. Both of 
these mean that it’s very important the standard library not include anything 
that makes force-unwrapping a common/routine operation (looking at you, 
UnsafeBufferPointer.baseAddress).

Given that arc4random, the recommended source of random numbers on Darwin, is 
always successful, requiring a force-unwrap when the user is using the default 
source doesn’t seem like the right move.


> On Wed, Oct 4, 2017 at 11:09 David Waite  > wrote:
> 
>> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> 
>> I agree with Felix’s concern, which is why I brought up the question, but 
>> ultimately the issue is unavoidable. It’s not down to global instance or 
>> not. If your source of random numbers is unseedable and may mix in 
>> additional entropy at any time, then it may fail at any time because when a 
>> hardware restart might happen may be transparent to the process. The user 
>> must know about this or else we are laying a trap (pun intended).
> 
> I'm of the mindset (which might be controversial) that we should attempt to 
> expose legacy and cryptographically secure random number generators, even a 
> mixed algorithmic/entropy source like /dev/urandom, but that we should not 
> expose /dev/random at all. If someone is trying to use /dev/random 
> legitimately (such as to generate one-time-pads) they will have to take into 
> account that systems like linux still use algorithmic entropy to drive 
> /dev/random. If someone really has this sort of use case, they have exceeded 
> the bounds of the system randomness protocol.
> 
> Without /dev/random support as a requirement, the only failure cases I know 
> of are reading too much random data in one operation (which could be solved 
> by repeated calls) or calling before sufficient entropy has been set up in 
> /dev/urandom (such as in a system startup process). I'd be fine with the 
> second one being a special case, and such systems needing to know use of the 
> /dev/urandom -backed generator before randomness has been set up will trap or 
> return predictable information on certain platforms.
> 
> -DW
> ___
> 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 Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon > > wrote:
>> 
>>> On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> - I’d love to see several of the most common random kinds supported, and I 
>>> agree it would be nice (but not required IMO) for the default to be 
>>> cryptographically secure.
>> 
>> I would be very careful about choosing a "simple" solution. There is a log, 
>> sad history of languages trying to provide a "simple" random number 
>> generator and accidentally providing a powerful footgun instead. But:
>> 
>>> - We should avoid the temptation to nuke this mosquito with a heavy handed 
>>> solution designed to solve all of the world’s problems: For example, the 
>>> C++ random number stuff is crazily over-general.  The stdlib should aim to 
>>> solve (e.g.) the top 3 most common cases, and let a more specialized 
>>> external library solve the fully general problem (e.g. seed management, 
>>> every distribution imaginable, etc).
>> 
>> 
>> That's not to say we need to have seven engines and twenty distributions 
>> like C++ does. The standard library is not a statistics package; it exists 
>> to provide basic abstractions and fundamental functionality. I don't think 
>> it should worry itself with distributions at all. I think it needs to 
>> provide:
>> 
>>  1. The abstraction used to plug in different random number generators 
>> (i.e. an RNG protocol of some kind).
>> 
>>  2. APIs on existing standard library types which perform basic 
>> randomness-related functions correctly—essentially, encapsulating Knuth. 
>> (Specifically, I think selecting a random element from a collection (which 
>> also covers generating a random integer in a range), shuffling a mutable 
>> collection, and generating a random float will do the trick.)
>> 
>>  3. A default RNG with a conservative design that will sometimes be too 
>> slow, but will never be insufficiently random.
>> 
>> If you want to pick elements with a Poisson distribution, go get a 
>> statistics framework; if you want repeatable random numbers for testing, use 
>> a seedable PRNG from XCTest or some other test tools package. These can 
>> leverage the standard library's RNG protocol to work with existing random 
>> number generators or random number consumers.
> 
> +1 to this general plan!

This pretty much exactly matches my preferences. 

If random numbers go into the std lib, they should  being able to customize the 
source of randomness for speed or test reproducibility, but default to 
something sensible without the user having to know it’s configurable. On Darwin 
that default should be based on arc4random(3). The std lib doesn’t need to 
provide other non-default random sources. Non-random sources for testing should 
be part of test frameworks and plug in easily.

The proposal should include shuffle and random element from collection, which 
are much-requested and not really the controversial part so won't hold up the 
overall progress of the proposal.

(and no need for distributions other than uniform IMO,  or otherwise)

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

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

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

[Mike Sanderson via swift-evolution]

After reading the original proposal and the Unicode Annex #31 document that
underlies it (https://unicode.org/reports/tr31/) I think that  the existing
work as an underlying layer could help frame the discussion and push it
forward.

Although I do see the concerns about defining things too strictly in
Unicode terms, the proposal brings in some really helpful work without
really tethering Swift to Unicode categories now or in the future. If
nothing else, throwing out the Unicode framework to start from scratch was
always likely to send the discussion into a massive detailed, unstructured
discussion of how to handle individual characters, which seems to be what
happened.

Particularly regarding identifiers, taking advantage of the Unicode work on
Unicode characters seems to be more promising to make progress than
starting from scratch.

My suggestion is to revive the proposal in part, keeping identifier work
and leaving operator work at the structural level:

1) Identifiers: Swift valid identifier characters will be aligned with UAX#31,
with exceptions.
2) Operators: Swift valid operator characters will be defined as an
arbitrary list, subject to community discussion within the Unicode
structure.

Identifiers:

The existing Unicode work in document UAX#31 is entirely about identifiers
and like the proposal authors, I think Swift can use this, with exceptions,
as the proposal specifies. In particular, the work in UAX#31 for
identifiers seems well-thought out and worthy of inclusion, and specifies
that individual programming languages can define their syntax *relative* to
these defaults, which is probably what Swift wants to do. 1) Swift
definitely will have "_" as a valid identifier-head. 2) Swift may need
additional rules for using Emoji as identifiers.

This is described more clearly later in the proposal, under
details-identifiers https://github.com/xwu/swift-evolution/blob/master/
proposals/-refining-identifier-and-operator-symbology.md#identifiers It
also has some guidelines on identifier equivalence that would be worth
pulling in.

Not sure if there is objection to the identifier part of the proposal. It
may have been phrased too prescriptively in terms of Unicode, but that
doesn't seem to be the intent.

Operators:

Unicode doesn't provide any guidance on operators, so what Swift includes
is arbitrary regardless. The rule in the proposal was solid but, first, too
complex: Default operator characters would be all unicode characters 1)
tagged by Unicode as 1a) "Pattern Syntax" characters and 1b) "Mathematical"
but 2) excluding characters in the blocks for 2a) "Geometric Shapes", 2b)
"Miscellaneous Symbols" and 2c) "Miscellaneous Technical". I can see why
this was considered too complex, but as an attempt for a non-arbitrary
definition it was a great start.

So the Swit list of valid operatior characters is arbitrary: embrace it.

Right now Swift's arbitrary list of Unicode ranges that are valid
operator-head or operator-character is unreadable and therefore mostly
useless for looking up which characters are valid (
https://developer.apple.com/library/content/documentation/
Swift/Conceptual/Swift_Programming_Language/LexicalStructure
.html#//apple_ref/doc/uid/TP40014097-CH30-ID418). It's introduced in text
as:

Custom operators can begin with one of the ASCII characters /, =, -, +, !,
> *, %, <, >, &, |, ^, ?, or ~, or one of the Unicode characters defined in
> the grammar below (which include characters from the Mathematical
> Operators, Miscellaneous Symbols, and Dingbats Unicode blocks, among
> others). After the first character, combining Unicode characters are also
> allowed.


This description is more helpful. Discussions of characters should make
reference to which code blocks they belong to, and to attempt to align with
Unicode groupings or categories when it makes sense to do so.

The online "UnicodeSet" functionality is very useful for seeing what
characters are included (https://unicode.org/cldr/utility/list-unicodeset.
jsp). For the current Swift 4 Language Reference, I made a list to see what
was included, which for this tool required manually expanding some ranges
and making a few other inferences, i.e., Swift allows the "dingbats" code
block with the exception of "Dingbat circled digits."

You can see the unicode-set list of existing Swift http://bit.ly/2yYzduM
(warning: may not be perfect).

The UnicodeSet tool doesn't scale very well for discussions. Regardless, it
would be very helpful if the final lists were accordingly grouped by
Unicode block or subhead, together with at least some descriptions /
examples:

*Ascii*
/­  =­  -­  +­  !­  *­  %­  <­  >­  &­  |­  ^­  ~­  ?

*Latin 1 Supplement*
Latin-1 punctuation and symbols: (INVERTED EXCLAMATION MARK) U+00A1–U+00A7,
U+00A9, U+00AB, U+00AC, U+00AE, U+00B0–U+00B1, U+00B6, U+00BB
(RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK)
Punctuation: U+00BF (INVERTED QUESTION MARK)
Mathematical operator: U+00D7 (MULTIPLICATION SIGN), U+00F7 

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

[Dave DeLong via swift-evolution]

Couldn’t the generators just do seeding at init time, and then throw or return 
nil if it fails, for whatever reason?

Dave

> On Oct 4, 2017, at 12:28 PM, Jacob Williams via swift-evolution 
>  wrote:
> 
> I agree with Dave’s assertion that this should be in a separate Random 
> library. Not every project needs random numbers and there could possibly be a 
> SecureRandom that exclusively uses CSPRNGs for it’s functionality.
> 
> I also agree that trapping is not a preferred behavior. Optionals are 
> slightly better, but in many instances the developer doesn’t care if the 
> random number is secure or non-reproducible. They really just want some 
> number within a specified range that “seems” random enough for that instant. 
> SecureRandom numbers could be optional or trap as lacking entropy might 
> significantly effect the usage of the random number.
> 
> 
>> On Oct 4, 2017, at 10:33 AM, Félix Cloutier via swift-evolution 
>> > wrote:
>> 
>> Anything that hasn't killed the process seems fine, and you have to start 
>> from `main` for anything else. On iOS, you can be suspended at any time, but 
>> the program will only continue from the point that it was suspended if it 
>> hasn't been torn down; otherwise, it has to restart from the beginning and 
>> reload the known UI state that it is responsible for saving. Unless we go 
>> out of our way to destroy the PRNG, it won't go away from under the 
>> program's feet. I'm not aware of any OS that will core dump programs on 
>> shutdown and try to rehydrate them on reboot.
>> 
>> Félix
>> 
>>> Le 4 oct. 2017 à 03:05, Xiaodi Wu >> > a écrit :
>>> 
>>> On Wed, Oct 4, 2017 at 04:55 Xiaodi Wu >> > wrote:
>>> Seems like the API would be actively hiding he possibility of failure so 
>>> that you’d have to be in the know to prevent it. Those who don’t know about 
>>> it would be hunting down a ghost as they’re trying to debug, especially if 
>>> their program crashes rarely, stochastically, and non-reproducibly because 
>>> a third party library calls random() in code they can’t see. I think this 
>>> makes trapping the least acceptable of all options.
>>> 
>>> I agree with Felix’s concern, which is why I brought up the question, but 
>>> ultimately the issue is unavoidable. It’s not down to global instance or 
>>> not. If your source of random numbers is unseedable and may mix in 
>>> additional entropy at any time, then it may fail at any time because when a 
>>> hardware restart might happen may be transparent to the process. The user 
>>> must know about this or else we are laying a trap (pun intended).
>>> 
>>> On Wed, Oct 4, 2017 at 04:49 Jonathan Hull >> > wrote:
>>> @Xiaodi:  What do you think of the possibility of trapping in cases of low 
>>> entropy, and adding an additional global function that checks for entropy 
>>> so that conscientious programmers can avoid the trap and provide an 
>>> alternative (or error message)?
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
 On Oct 4, 2017, at 2:41 AM, Xiaodi Wu > wrote:
 
 
 On Wed, Oct 4, 2017 at 02:39 Félix Cloutier > wrote:
 I'm really not enthusiastic about `random() -> Self?` or `random() throws 
 -> Self` when the only possible error is that some global object hasn't 
 been initialized.
 
 The idea of having `random` straight on integers and floats and 
 collections was to provide a simple interface, but using a global CSPRNG 
 for those operations comes at a significant usability cost. I think that 
 something has to go:
 
 Drop the random methods on FixedWidthInteger, FloatingPoint
 ...or drop the CSPRNG as a default
 Drop the optional/throws, and trap on error
 
 I know I wouldn't use the `Int.random()` method if I had to unwrap every 
 single result, when getting one non-nil result guarantees that the program 
 won't see any other nil result again until it restarts.
 
 From the perspective of an app that can be suspended and resumed at any 
 time, “until it restarts” could be as soon as the next invocation of 
 `Int.random()`, could it not?
 
 
 Félix
 
> Le 3 oct. 2017 à 23:44, Jonathan Hull  > a écrit :
> 
> I like the idea of splitting it into 2 separate “Random” proposals.
> 
> The first would have Xiaodi’s built-in CSPRNG which only has the 
> interface:
> 
> On FixedWidthInteger:
>   static func random()throws -> Self
>   static func random(in range: ClosedRange)throws -> Self
> 
> On Double:
>   static func random()throws -> Double
>   static func 

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

[Jacob Williams via swift-evolution]

I agree with Dave’s assertion that this should be in a separate Random library. 
Not every project needs random numbers and there could possibly be a 
SecureRandom that exclusively uses CSPRNGs for it’s functionality.

I also agree that trapping is not a preferred behavior. Optionals are slightly 
better, but in many instances the developer doesn’t care if the random number 
is secure or non-reproducible. They really just want some number within a 
specified range that “seems” random enough for that instant. SecureRandom 
numbers could be optional or trap as lacking entropy might significantly effect 
the usage of the random number.


> On Oct 4, 2017, at 10:33 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> Anything that hasn't killed the process seems fine, and you have to start 
> from `main` for anything else. On iOS, you can be suspended at any time, but 
> the program will only continue from the point that it was suspended if it 
> hasn't been torn down; otherwise, it has to restart from the beginning and 
> reload the known UI state that it is responsible for saving. Unless we go out 
> of our way to destroy the PRNG, it won't go away from under the program's 
> feet. I'm not aware of any OS that will core dump programs on shutdown and 
> try to rehydrate them on reboot.
> 
> Félix
> 
>> Le 4 oct. 2017 à 03:05, Xiaodi Wu > > a écrit :
>> 
>> On Wed, Oct 4, 2017 at 04:55 Xiaodi Wu > > wrote:
>> Seems like the API would be actively hiding he possibility of failure so 
>> that you’d have to be in the know to prevent it. Those who don’t know about 
>> it would be hunting down a ghost as they’re trying to debug, especially if 
>> their program crashes rarely, stochastically, and non-reproducibly because a 
>> third party library calls random() in code they can’t see. I think this 
>> makes trapping the least acceptable of all options.
>> 
>> I agree with Felix’s concern, which is why I brought up the question, but 
>> ultimately the issue is unavoidable. It’s not down to global instance or 
>> not. If your source of random numbers is unseedable and may mix in 
>> additional entropy at any time, then it may fail at any time because when a 
>> hardware restart might happen may be transparent to the process. The user 
>> must know about this or else we are laying a trap (pun intended).
>> 
>> On Wed, Oct 4, 2017 at 04:49 Jonathan Hull > > wrote:
>> @Xiaodi:  What do you think of the possibility of trapping in cases of low 
>> entropy, and adding an additional global function that checks for entropy so 
>> that conscientious programmers can avoid the trap and provide an alternative 
>> (or error message)?
>> 
>> Thanks,
>> Jon
>> 
>> 
>>> On Oct 4, 2017, at 2:41 AM, Xiaodi Wu >> > wrote:
>>> 
>>> 
>>> On Wed, Oct 4, 2017 at 02:39 Félix Cloutier >> > wrote:
>>> I'm really not enthusiastic about `random() -> Self?` or `random() throws 
>>> -> Self` when the only possible error is that some global object hasn't 
>>> been initialized.
>>> 
>>> The idea of having `random` straight on integers and floats and collections 
>>> was to provide a simple interface, but using a global CSPRNG for those 
>>> operations comes at a significant usability cost. I think that something 
>>> has to go:
>>> 
>>> Drop the random methods on FixedWidthInteger, FloatingPoint
>>> ...or drop the CSPRNG as a default
>>> Drop the optional/throws, and trap on error
>>> 
>>> I know I wouldn't use the `Int.random()` method if I had to unwrap every 
>>> single result, when getting one non-nil result guarantees that the program 
>>> won't see any other nil result again until it restarts.
>>> 
>>> From the perspective of an app that can be suspended and resumed at any 
>>> time, “until it restarts” could be as soon as the next invocation of 
>>> `Int.random()`, could it not?
>>> 
>>> 
>>> Félix
>>> 
 Le 3 oct. 2017 à 23:44, Jonathan Hull > a écrit :
 
 I like the idea of splitting it into 2 separate “Random” proposals.
 
 The first would have Xiaodi’s built-in CSPRNG which only has the interface:
 
 On FixedWidthInteger:
static func random()throws -> Self
static func random(in range: ClosedRange)throws -> Self
 
 On Double:
static func random()throws -> Double
static func random(in range: ClosedRange)throws -> Double
 
 (Everything else we want, like shuffled(), could be built in later 
 proposals by calling those functions)
 
 The other option would be to remove the ‘throws’ from the above functions 
 (perhaps fatalError-ing), and provide an additional function which can be 
 used to check that there is enough entropy 

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

[Nevin Brackett-Rozinsky via swift-evolution]

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

> This is unduly restrictive; @_versioned (despite being the wrong spelling)
> is what we want here. To be callable from an inlinable function, internal
> things need only be visible in terms of public ABI, not necessarily
> inlinable, just as public things need only be public and not necessarily
> inlinable.
>

Unduly restrictive is fine for now, we don’t need to make @_versioned ready
for primetime just to roll out @inlinable. We can begin with the semantics
that @inlinable functions can only call things which are themselves either
@inlinable or public, and then subsequently in the future we can expand it
to “…or whatever-we-end-up-calling-@_versioned”.

That way the scope of this proposal can stay narrow and self-contained.

Nevin



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

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

[Joe Groff via swift-evolution]

> On Oct 4, 2017, at 9:46 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
> 
> On Oct 3, 2017, at 10:03 PM, Chris Lattner  wrote:
> 
>> 
>>> On Oct 3, 2017, at 10:04 AM, Joe Groff  wrote:
>>> 
>>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution 
>>>  wrote:
 
 The major question I have is “why yet another attribute”.  The thread 
 about exhaustive/extensible enums is similarly proposing introducing 
 another one-off way to be enums fragile, and this is directly related just 
 for function-like things.
 
 I’d love to see rationale in the proposal for why you’re not taking this 
 in one of these directions:
 
 1) Why not another level of access control?  There is a reasonable 
 argument that what you’re doing is making something “more public than 
 public” or that you’re making the “body also public”.  I’m not strongly in 
 favor of this design approach, but if you agree, the doc should explain 
 why you’re not in favor of it.
 
 2) Why can’t we have a single Swift-wide concept that unifies all of the 
 resilience ideas under a single umbrella like “fragile” - which indicates 
 that the body of a declaration is knowable to clients?  There is a very 
 reasonable holistic design where “fragile public func” makes its body 
 inlinable, and “fragile enum” similarly makes the cases knowable to the 
 client (thus making exhaustive switching a possibility).  I am strongly in 
 favor of this approach.
>>> 
>>> I'm of two minds on this. So far, it has seemingly been the case that, for 
>>> every kind of declaration, there's been exactly one resilience-related 
>>> attribute, and with blurry enough vision you could say they're all really 
>>> doing the same thing, "expose this declaration body directly to clients", 
>>> which only makes sense as a concept for public API. If these properties 
>>> hold, then sure, it might make sense to consider these all as one 
>>> "extra-public" concept. On the other hand, we don't know yet whether these 
>>> properties will hold in the long term as we're actively designing the 
>>> facilities we need for ABI stability and resilience. From an incremental, 
>>> iterative design perspective, I think it's wiser to keep them all separate 
>>> attributes, even if it's a bit messy in the short term. Once the design 
>>> stabilizes, we can look at whether it makes sense to fold related concepts 
>>> together. It's easier to fold different things together after the fact then 
>>> to try to separate things after they've been mixed together.
>> 
>> As I said above, I pretty strongly disagree with this approach.  It 
>> encourages a “one attribute/declmodifier/keyword per decl kind” approach, 
>> which is user hostile.  It doesn’t make sense for “exhaustive" to apply to 
>> enums, "@inlinable” to apply to function-like things, something else to 
>> apply to structs, something else to apply to classes, etc.
> 
> Premature abstraction is user-hostile too. These things all have subtly 
> different impacts on language semantics, some of which we're still 
> discovering as we develop their designs.

These are also ultimately all "power user" features that only a handful of 
first and second parties shipping binary frameworks need to think about. Apps 
don't need to care about this at all, and most packages outside the OS can be 
shipped as source or as fragile binaries, for which these sorts of attributes 
are unnecessary for the build system to (eventually) provide the desired 
performance.

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

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

[David Sweeris via swift-evolution]

On Oct 3, 2017, at 21:47, Chris Lattner > wrote:

> 
>> On Oct 3, 2017, at 4:05 PM, David Sweeris > > wrote:
>> 
>> 
>>> On Oct 2, 2017, at 10:06 PM, Chris Lattner >> > wrote:
>>> 
>>> On Oct 2, 2017, at 9:12 PM, David Sweeris via swift-evolution 
>>> > wrote:
> Keep in mind that Swift already goes far above and beyond in terms of 
> operators
 Yep, that's is a large part of why I'm such a Swift fan :-D
>>> 
>>> Fortunately, no one is seriously proposing a major curtailing of the 
>>> capabilities here, we’re just trying to rationalize the operator set, which 
>>> is a bit of a mess at present.
>> I guess I don't really understand why it's currently "a bit of a mess”.
> 
> Read the motivation/inconsistency section of:
> https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/-refining-identifier-and-operator-symbology.md
>  
> 
> 
>>> Set algebra is an illustrative example, because it is both used by people 
>>> who are experts and people who are not.  As far as policies go, I think it 
>>> makes sense for Swift libraries to define operator-like things as named 
>>> functions (e.g. “intersection") and also define operators (“∩”) which can 
>>> optionally be used in source bases that want them for convenience.  The 
>>> compiler and language cannot know whether a code base is written and 
>>> maintained by experts who know the symbols and who value their clarity 
>>> (over the difficulty typing and recognizing them), and this approach allows 
>>> maintainers of the codebase to pick their own policies.
>> Oh, yeah, I can't imagine a situation in which I'd think it'd be a good idea 
>> to not define a named function to go along with a unicode operator. I'm 
>> mainly concerned that we not limit the people in 5) unless we need to. And 
>> to be clear, if we actually need to, then I'm fine with doing that... It's 
>> just that -- like I said earlier in this message -- I don't clearly 
>> understand why this is a problem.
> 
> Sure, that’s fair.  This is an issue we’ve been tracking since the Swift 2.x 
> (!) days, so there is a lot of context that is probably not immediately 
> obvious if you haven’t been following it since then.  The proposal link above 
> talks about the damage that we still carry.

Oh! I didn't realize the proposal had already been written! Yeah, that clears 
things up quite a bit, thanks for posting it :-)

Xiaodi Wu, I’m sorry I ever doubted you :-)

- Dave Sweeris___
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

[Ole Begemann via swift-evolution]

How does @inlinable relate to the @_specialize attribute described in 
https://github.com/apple/swift/pull/6797 (original swift-evolution post 
about it: 
https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001449.html)?


Here's how I understand it:

@_specialize emits the specialized generic code (for the types specified 
in the @_specialize declaration) in the module binary (module A). The 
downside is that the author of module A has to decide for which types 
they want to emit specialized code. Clients of module A that need 
specialization for other types are out of luck.


@inlinable enables the optimizer to emit specialized code in the 
binaries that import module A. It shifts the decision what to specialize 
where it belongs (and where it can be made).


Is this understanding correct? Will @inlinable cover everything we'd 
need @_specialize for, or is the plan to make @_specialize public as 
well in the future?


Ole

On 02.10.17 22:31, 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 |map|method 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 

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

[Joe Groff via swift-evolution]

> On Oct 3, 2017, at 10:03 PM, Chris Lattner  wrote:
> 
> 
>> On Oct 3, 2017, at 10:04 AM, Joe Groff  wrote:
>> 
>>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> The major question I have is “why yet another attribute”.  The thread about 
>>> exhaustive/extensible enums is similarly proposing introducing another 
>>> one-off way to be enums fragile, and this is directly related just for 
>>> function-like things.
>>> 
>>> I’d love to see rationale in the proposal for why you’re not taking this in 
>>> one of these directions:
>>> 
>>> 1) Why not another level of access control?  There is a reasonable argument 
>>> that what you’re doing is making something “more public than public” or 
>>> that you’re making the “body also public”.  I’m not strongly in favor of 
>>> this design approach, but if you agree, the doc should explain why you’re 
>>> not in favor of it.
>>> 
>>> 2) Why can’t we have a single Swift-wide concept that unifies all of the 
>>> resilience ideas under a single umbrella like “fragile” - which indicates 
>>> that the body of a declaration is knowable to clients?  There is a very 
>>> reasonable holistic design where “fragile public func” makes its body 
>>> inlinable, and “fragile enum” similarly makes the cases knowable to the 
>>> client (thus making exhaustive switching a possibility).  I am strongly in 
>>> favor of this approach.
>> 
>> I'm of two minds on this. So far, it has seemingly been the case that, for 
>> every kind of declaration, there's been exactly one resilience-related 
>> attribute, and with blurry enough vision you could say they're all really 
>> doing the same thing, "expose this declaration body directly to clients", 
>> which only makes sense as a concept for public API. If these properties 
>> hold, then sure, it might make sense to consider these all as one 
>> "extra-public" concept. On the other hand, we don't know yet whether these 
>> properties will hold in the long term as we're actively designing the 
>> facilities we need for ABI stability and resilience. From an incremental, 
>> iterative design perspective, I think it's wiser to keep them all separate 
>> attributes, even if it's a bit messy in the short term. Once the design 
>> stabilizes, we can look at whether it makes sense to fold related concepts 
>> together. It's easier to fold different things together after the fact then 
>> to try to separate things after they've been mixed together.
> 
> As I said above, I pretty strongly disagree with this approach.  It 
> encourages a “one attribute/declmodifier/keyword per decl kind” approach, 
> which is user hostile.  It doesn’t make sense for “exhaustive" to apply to 
> enums, "@inlinable” to apply to function-like things, something else to apply 
> to structs, something else to apply to classes, etc.

Premature abstraction is user-hostile too. These things all have subtly 
different impacts on language semantics, some of which we're still discovering 
as we develop their designs.

-Joe

> 
> I’d rather that we define one “thing” which can be parameterized.  I’d 
> propose that that be named “fragile” because it appropriately carries 
> negative connotations.  If some declaration has multiple levels of fragility 
> that we want to support, we can allow it to be parameterized, e.g.:
> 
> /// C style fragility, all things about the decl are fragile.
> fragile struct Foo { … }
> 
> /// Just layout is fragile, but not other things (whatever they would be?)
> fragile(layout) struct Foo { … }
> 
> I pretty strongly believe that we should start with the default of having a 
> unifying principle that ties together all resilience concerns under a single 
> umbrella, and fission those concerns when we’re faced with something that 
> forces it.  Starting with them split and hoping that we’ll come around to 
> merging them someday is the wrong side of optimism IMO.
> 
> We’ve been talking about this approach for years, which is why I’m somewhat 
> surprised to see the new direction these things are taking.
> 
> -Chris
___
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 3, 2017, at 9:56 PM, Chris Lattner  wrote:
> 
> 
>> On Oct 3, 2017, at 9:50 AM, Joe Groff  wrote:
>> 
>> 
>> 
 On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution 
  wrote:
 
 We have discussed adding a "versioned @inlinable" variant that preserves 
 the public entry point for older clients, while making the declaration 
 inlinable for newer clients. This will likely be a separate proposal and 
 discussion.
 
>>> 5) It eliminates this complexity.
>> 
>> It wouldn't avoid the complexity, because we want the "non-ABI, 
>> always-emit-into-client" behavior for the standard library. For the 
>> soon-to-be-ABI-stable libraries where @inlinable even matters, such as the 
>> standard library and Apple SDK overlays, there's pretty much perfect overlap 
>> between things we want to inline and things we don't want to take up binary 
>> space and ABI surface in binaries, so the behavior Slava proposes seems like 
>> the right default. 
> 
> I disagree.  The semantics being proposed perfectly overlap with the 
> transitional plan for overlays (which matters for the next few years), but 
> they are the wrong default for anything other than overlays and the wrong 
> thing for long term API evolution over the next 20 years.

I disagree with this. 'inline' functions in C and C++ have to be backed by a 
symbol in the binary in order to guarantee function pointer identity, but we 
don't have that constraint. Without that constraint, there's almost no way that 
having a fallback definition in the binary is better:

- It becomes an ABI compatibility liability that has to be preserved forever. 
- It increases binary size for a function that's rarely used, and which is 
often much larger as an outlined generic function than the simple operation 
that can be inlined into client code. Inlining makes the most sense when the 
inlined operation is smaller than a function call, so in many cases the net 
dylib + executable size would increase.
- It increases the uncertainty of the behavior client code sees. If an 
inlinable function must always be emitted in the client, then client code 
*always* gets the current definition. If an inlinable function calls into the 
dylib when the compiler chooses not to inline it, then you may get the current 
definition, or you may get an older definition from any published version of 
the dylib. Ideally these all behave the same if the function is inlinable, but 
quirks are going to be inevitable.

-Joe 

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

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

[Joe Groff via swift-evolution]

> On Oct 3, 2017, at 9:59 PM, Slava Pestov  wrote:
> 
> 
> 
>>> On Oct 3, 2017, at 9:56 PM, Chris Lattner  wrote:
>>> 
>>> 
 On Oct 3, 2017, at 9:50 AM, Joe Groff  wrote:
 
 
 
> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> We have discussed adding a "versioned @inlinable" variant that preserves 
> the public entry point for older clients, while making the declaration 
> inlinable for newer clients. This will likely be a separate proposal and 
> discussion.
> 
 5) It eliminates this complexity.
>>> 
>>> It wouldn't avoid the complexity, because we want the "non-ABI, 
>>> always-emit-into-client" behavior for the standard library. For the 
>>> soon-to-be-ABI-stable libraries where @inlinable even matters, such as the 
>>> standard library and Apple SDK overlays, there's pretty much perfect 
>>> overlap between things we want to inline and things we don't want to take 
>>> up binary space and ABI surface in binaries, so the behavior Slava proposes 
>>> seems like the right default. 
>> 
>> I disagree.  The semantics being proposed perfectly overlap with the 
>> transitional plan for overlays (which matters for the next few years), but 
>> they are the wrong default for anything other than overlays and the wrong 
>> thing for long term API evolution over the next 20 years.
> 
> 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.

-Joe___
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]

Anything that hasn't killed the process seems fine, and you have to start from 
`main` for anything else. On iOS, you can be suspended at any time, but the 
program will only continue from the point that it was suspended if it hasn't 
been torn down; otherwise, it has to restart from the beginning and reload the 
known UI state that it is responsible for saving. Unless we go out of our way 
to destroy the PRNG, it won't go away from under the program's feet. I'm not 
aware of any OS that will core dump programs on shutdown and try to rehydrate 
them on reboot.

Félix

> Le 4 oct. 2017 à 03:05, Xiaodi Wu  a écrit :
> 
> On Wed, Oct 4, 2017 at 04:55 Xiaodi Wu  > wrote:
> Seems like the API would be actively hiding he possibility of failure so that 
> you’d have to be in the know to prevent it. Those who don’t know about it 
> would be hunting down a ghost as they’re trying to debug, especially if their 
> program crashes rarely, stochastically, and non-reproducibly because a third 
> party library calls random() in code they can’t see. I think this makes 
> trapping the least acceptable of all options.
> 
> I agree with Felix’s concern, which is why I brought up the question, but 
> ultimately the issue is unavoidable. It’s not down to global instance or not. 
> If your source of random numbers is unseedable and may mix in additional 
> entropy at any time, then it may fail at any time because when a hardware 
> restart might happen may be transparent to the process. The user must know 
> about this or else we are laying a trap (pun intended).
> 
> On Wed, Oct 4, 2017 at 04:49 Jonathan Hull  > wrote:
> @Xiaodi:  What do you think of the possibility of trapping in cases of low 
> entropy, and adding an additional global function that checks for entropy so 
> that conscientious programmers can avoid the trap and provide an alternative 
> (or error message)?
> 
> Thanks,
> Jon
> 
> 
>> On Oct 4, 2017, at 2:41 AM, Xiaodi Wu > > wrote:
>> 
>> 
>> On Wed, Oct 4, 2017 at 02:39 Félix Cloutier > > wrote:
>> I'm really not enthusiastic about `random() -> Self?` or `random() throws -> 
>> Self` when the only possible error is that some global object hasn't been 
>> initialized.
>> 
>> The idea of having `random` straight on integers and floats and collections 
>> was to provide a simple interface, but using a global CSPRNG for those 
>> operations comes at a significant usability cost. I think that something has 
>> to go:
>> 
>> Drop the random methods on FixedWidthInteger, FloatingPoint
>> ...or drop the CSPRNG as a default
>> Drop the optional/throws, and trap on error
>> 
>> I know I wouldn't use the `Int.random()` method if I had to unwrap every 
>> single result, when getting one non-nil result guarantees that the program 
>> won't see any other nil result again until it restarts.
>> 
>> From the perspective of an app that can be suspended and resumed at any 
>> time, “until it restarts” could be as soon as the next invocation of 
>> `Int.random()`, could it not?
>> 
>> 
>> Félix
>> 
>>> Le 3 oct. 2017 à 23:44, Jonathan Hull >> > a écrit :
>>> 
>>> I like the idea of splitting it into 2 separate “Random” proposals.
>>> 
>>> The first would have Xiaodi’s built-in CSPRNG which only has the interface:
>>> 
>>> On FixedWidthInteger:
>>> static func random()throws -> Self
>>> static func random(in range: ClosedRange)throws -> Self
>>> 
>>> On Double:
>>> static func random()throws -> Double
>>> static func random(in range: ClosedRange)throws -> Double
>>> 
>>> (Everything else we want, like shuffled(), could be built in later 
>>> proposals by calling those functions)
>>> 
>>> The other option would be to remove the ‘throws’ from the above functions 
>>> (perhaps fatalError-ing), and provide an additional function which can be 
>>> used to check that there is enough entropy (so as to avoid the crash or 
>>> fall back to a worse source when the CSPRNG is unavailable).
>>> 
>>> 
>>> 
>>> Then a second proposal would bring in the concept of RandomSources 
>>> (whatever we call them), which can return however many random bytes you ask 
>>> for… and a protocol for types which know how to initialize themselves from 
>>> those bytes.  That might be spelled like 'static func random(using: 
>>> RandomSource)->Self'.  As a convenience, the source would also be able to 
>>> create FixedWidthIntegers and Doubles (both with and without a range), and 
>>> would also have the coinFlip() and oneIn(UInt)->Bool functions. Most types 
>>> should be able to build themselves off of that.  There would be a default 
>>> source which is built from the first protocol.
>>> 
>>> I also really think we should have a concept of Repeatably-Random as a 
>>> subprotocol 

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

[Taylor Swift via swift-evolution]

The implementation is complete and building successfully:
https://github.com/apple/swift/pull/12200

On Sat, Sep 30, 2017 at 2:56 PM, Taylor Swift via swift-evolution <
swift-evolution@swift.org> wrote:

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

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

[Dave DeLong via swift-evolution]

Riffing off this a bit…

I’d like to see minimal Random support in the stdlib, and then all this 
specialization stuff in a “non-standard” library. Ie, a library that ships with 
Swift, but is not imported by default.

As I’m developing apps, I don’t need the massive autocompletion overload and 
cognitive overhead that comes from trying to understand all these proposed 
protocols and use-cases unless I am actually going to be needing randomization. 
If I need randomization, I should be explicitly opting-in to it by doing 
“import Random”.

Dave


> On Oct 3, 2017, at 10:31 PM, Alejandro Alonso via swift-evolution 
>  wrote:
> 
> I really like the schedule here. After reading for a while, I do agree with 
> Brent that stdlib should very primitive in functionality that it provides. I 
> also agree that the most important part right now is designing the internal 
> crypto on which the numeric types use to return their respected random 
> number. On the discussion of how we should handle not enough entropy with the 
> device random, from a users perspective it makes sense that calling .random 
> should just give me a random number, but from a developers perspective I see 
> Optional being the best choice here. While I think blocking could, in most 
> cases, provide the user an easier API, we have to do this right and be safe 
> here by providing a value that indicates that there is room for error here. 
> As for the generator abstraction, I believe there should be a bare basic 
> protocol that sets a layout for new generators and should be focusing on its 
> requirements. 
> 
> Whether or not RandomAccessCollection and MutableCollection should get 
> .random and .shuffle/.shuffled in this first proposal is completely up in the 
> air for me. It makes sense, to me, to include the .random in this proposal 
> and open another one .shuffle/.shuffled, but I can see arguments that should 
> say we create something separate for these two, or include all of it in this 
> proposal.
> 
> - Alejandro
> 
> On Sep 27, 2017, 7:29 PM -0500, Xiaodi Wu , wrote:
>> 
>> On Wed, Sep 27, 2017 at 00:18 Félix Cloutier > > wrote:
>>> Le 26 sept. 2017 à 16:14, Xiaodi Wu >> > a écrit :
>>> 
>> 
>>> On Tue, Sep 26, 2017 at 11:26 AM, Félix Cloutier >> > wrote:
>>> 
>>> It's possible to use a CSPRNG-grade algorithm and seed it once to get a 
>>> reproducible sequence, but when you use it as a CSPRNG, you typically feed 
>>> entropy back into it at nondeterministic points to ensure that even if you 
>>> started with a bad seed, you'll eventually get to an alright state. Unless 
>>> you keep track of when entropy was mixed in and what the values were, 
>>> you'll never get a reproducible CSPRNG.
>>> 
>>> We would give developers a false sense of security if we provided them with 
>>> CSPRNG-grade algorithms that we called CSPRNGs and that they could seed 
>>> themselves. Just because it says "crypto-secure" in the name doesn't mean 
>>> that it'll be crypto-secure if it's seeded with time(). Therefore, 
>>> "reproducible" vs "non-reproducible" looks like a good distinction to me.
>>> 
>>> I disagree here, in two respects:
>>> 
>>> First, whether or not a particular PRNG is cryptographically secure is an 
>>> intrinsic property of the algorithm; whether it's "reproducible" or not is 
>>> determined by the published API. In other words, the distinction between 
>>> CSPRNG vs. non-CSPRNG is important to document because it's semantics that 
>>> cannot be deduced by the user otherwise, and it is an important one for 
>>> writing secure code because it tells you whether an attacker can predict 
>>> future outputs based only on observing past outputs. "Reproducible" in the 
>>> sense of seedable or not is trivially noted by inspection of the published 
>>> API, and it is rather immaterial to writing secure code.
>> 
>> 
>> Cryptographically secure is not a property that I'm comfortable applying to 
>> an algorithm. You cannot say that you've made a cryptographically secure 
>> thing just because you've used all the right algorithms: you also have to 
>> use them right, and one of the most critical components of a 
>> cryptographically secure PRNG is its seed.
>> 
>> A cryptographically secure algorithm isn’t sufficient, but it is necessary. 
>> That’s why it’s important to mark them as such. If I'm a careful developer, 
>> then it is absolutely important to me to know that I’m using a PRNG with a 
>> cryptographically secure algorithm, and that the particular implementation 
>> of that algorithm is correct and secure.
>> 
>> It is a *feature* of a lot of modern CSPRNGs that you can't seed them:
>> 
>> You cannot seed or add entropy to std::random_device
>> 
>> Although std::random_device may in practice be backed by a software 

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

[Mike Kluev via swift-evolution]

On 4 October 2017 at 14:24, Alex Blewitt  wrote:

func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool {
> return left && right()
> }
>

FTM, it would be nice to be able to "syntax sugar-ize" it into a better
looking:

func &&& (left: Bool, right: lazy Bool) -> Bool {
return left && right  // no parens here
}

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

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

[Xiaodi Wu via swift-evolution]

If trapping is OK, then surely returning Optional is superior; any user who
is OK with trapping can make that decision for themselves by writing
`random()!`. Everyone else can then see clearly that trapping is a
possibility, which is important.
On Wed, Oct 4, 2017 at 11:09 David Waite 
wrote:

>
> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> I agree with Felix’s concern, which is why I brought up the question, but
> ultimately the issue is unavoidable. It’s not down to global instance or
> not. If your source of random numbers is unseedable and may mix in
> additional entropy at any time, then it may fail at any time because when a
> hardware restart might happen may be transparent to the process. The user
> must know about this or else we are laying a trap (pun intended).
>
>
> I'm of the mindset (which might be controversial) that we should attempt
> to expose legacy and cryptographically secure random number generators,
> even a mixed algorithmic/entropy source like /dev/urandom, but that we
> should not expose /dev/random at all. If someone is trying to use
> /dev/random legitimately (such as to generate one-time-pads) they will have
> to take into account that systems like linux still use algorithmic entropy
> to drive /dev/random. If someone really has this sort of use case, they
> have exceeded the bounds of the system randomness protocol.
>
> Without /dev/random support as a requirement, the only failure cases I
> know of are reading too much random data in one operation (which could be
> solved by repeated calls) or calling before sufficient entropy has been set
> up in /dev/urandom (such as in a system startup process). I'd be fine with
> the second one being a special case, and such systems needing to know use
> of the /dev/urandom -backed generator before randomness has been set up
> will trap or return predictable information on certain platforms.
>
> -DW
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

> On Oct 4, 2017, at 4:05 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
> I agree with Felix’s concern, which is why I brought up the question, but 
> ultimately the issue is unavoidable. It’s not down to global instance or not. 
> If your source of random numbers is unseedable and may mix in additional 
> entropy at any time, then it may fail at any time because when a hardware 
> restart might happen may be transparent to the process. The user must know 
> about this or else we are laying a trap (pun intended).

I'm of the mindset (which might be controversial) that we should attempt to 
expose legacy and cryptographically secure random number generators, even a 
mixed algorithmic/entropy source like /dev/urandom, but that we should not 
expose /dev/random at all. If someone is trying to use /dev/random legitimately 
(such as to generate one-time-pads) they will have to take into account that 
systems like linux still use algorithmic entropy to drive /dev/random. If 
someone really has this sort of use case, they have exceeded the bounds of the 
system randomness protocol.

Without /dev/random support as a requirement, the only failure cases I know of 
are reading too much random data in one operation (which could be solved by 
repeated calls) or calling before sufficient entropy has been set up in 
/dev/urandom (such as in a system startup process). I'd be fine with the second 
one being a special case, and such systems needing to know use of the 
/dev/urandom -backed generator before randomness has been set up will trap or 
return predictable information on certain platforms.

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

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

[Mike Kluev via swift-evolution]

On 4 October 2017 at 14:24, Alex Blewitt  wrote:

> On 4 October 2017 at 13:41, Alex Blewitt  wrote:
>
>>
>> The difference between the & and && operators isn't to do with the
>> implicit conversions; it's to do with whether both sides of the expression
>> are evaluated or not.
>>
>
> However, you can wrap the second argument in an @autoclosure, which means
> it replaces the body of the expression with a function that evaluates the
> expression automatically:
>
> infix operator &&&: LogicalConjunctionPrecedence
>
> func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool {
> return left && right()
> }
>

great. as you just shown, the difference of short-circuiting or not is not
inside the operator declaration itself (like it is defined in C)
but in the actual operator implementation, so we can have:

infix operator &&&: LogicalConjunctionPrecedence

func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool {
return left && right()
}

func &&&(left: Int, right: Int) -> Int {
return left & right
}

where the logical one short-circuits and bit-wise one doesn't.

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

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

[Alex Blewitt via swift-evolution]

> On 4 Oct 2017, at 14:12, Mike Kluev  wrote:
> 
> On 4 October 2017 at 13:41, Alex Blewitt  > wrote:
> 
> The difference between the & and && operators isn't to do with the implicit 
> conversions; it's to do with whether both sides of the expression are 
> evaluated or not.
> 
> false && system('rm -rf')
> 
> You really don't want to do that if both sides are executed ...
> 
> actually, thanks for bringing this up as it leads up to a question:
> 
> how in swift do i define my &&& operator (that i may need for whatever 
> reason, e.g. logging) that will short-circuit
> the calculation of right hand side if the left hand side is false?
> 
> infix operator &&&: LogicalConjunctionPrecedence
> 
> func &&&(left: Bool, right: Bool) -> Bool {
>   return left && right
> }
> 
> as written it doesn't short-circuit. is it possible at all in swift?

When you call the function, the arguments will be evaluated prior to the 
function body - so this won't work (as you correctly noted).

However, you can wrap the second argument in an @autoclosure, which means it 
replaces the body of the expression with a function that evaluates the 
expression automatically:

infix operator &&&: LogicalConjunctionPrecedence

func &&&(left: Bool, right: @autoclosure () -> Bool) -> Bool {
return left && right()
}

func no() -> Bool {
  print("no")
  return false
}

func yes() -> Bool {
  print("yes")
  return true
}

print(no() &&& yes())

no
false

Alex

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

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

[Mike Kluev via swift-evolution]

On 4 October 2017 at 13:41, Alex Blewitt  wrote:

>
> The difference between the & and && operators isn't to do with the
> implicit conversions; it's to do with whether both sides of the expression
> are evaluated or not.
>
> false && system('rm -rf')
>
> You really don't want to do that if both sides are executed ...
>

actually, thanks for bringing this up as it leads up to a question:

how in swift do i define my &&& operator (that i may need for whatever
reason, e.g. logging) that will short-circuit
the calculation of right hand side if the left hand side is false?

infix operator &&&: LogicalConjunctionPrecedence

func &&&(left: Bool, right: Bool) -> Bool {
return left && right
}

as written it doesn't short-circuit. is it possible at all in swift?

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

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

[Alex Blewitt via swift-evolution]

> On 4 Oct 2017, at 13:55, Mike Kluev  wrote:
> 
> On 4 October 2017 at 13:41, Alex Blewitt  > wrote:
>> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution 
>> > wrote:
>> 
>> speaking of &&, was it just a copy-paste from C or is there a more 
>> fundamental reason to use that instead of &? in C they had to use two 
>> different operators because of the implicit int <-> bool promotions, but in 
>> swift "true & false" vs "1 & 2" would have been distinguishable.
> 
> The difference between the & and && operators isn't to do with the implicit 
> conversions; it's to do with whether both sides of the expression are 
> evaluated or not.
> 
> false && system('rm -rf')
> 
> You really don't want to do that if both sides are executed ...
> 
> true. however what would stop the hypothetical "logical &" operator to not 
> evaluate the right hand side if the left 
> side is false similar to how && behaves? yes, it would make it more different 
> to the "bitwise &" operator, but they are
> already a bit different.

Whether you are dealing with boolean/int types and whether you short-circuit 
the operators are orthogonal concerns.

> (it was always backwards to me even in C: bitwise *single* & is for and-ing 
> *multiple* bit pairs, whilst a
> *multi-character* && is for and-ing a single bool pair.)

The && (c.f. ||) is explicitly for short-circuiting and is nothing to do with 
bit pairs or booleans, by specification.

See e.g. section 6.5.13 and 6.5.14.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

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

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

[Mike Kluev via swift-evolution]

On 4 October 2017 at 13:41, Alex Blewitt  wrote:

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

true. however what would stop the hypothetical "logical &" operator to not
evaluate the right hand side if the left
side is false similar to how && behaves? yes, it would make it more
different to the "bitwise &" operator, but they are
already a bit different.

(it was always backwards to me even in C: bitwise *single* & is for and-ing
*multiple* bit pairs, whilst a
*multi-character* && is for and-ing a single bool pair.)

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

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

[Swift via swift-evolution]

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

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

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

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

Dave

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

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

[Alex Blewitt via swift-evolution]

> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution 
>  wrote:
> 
> on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong  >
>   wrote:
> 
> > Because, ideally, I’d love to be able to do:
> > 
> > infix operator and: LogicalConjunctionPrecedence // or whatever the 
> > precedence is called
> > func and(lhs: Bool, rhs: Bool) → Bool { return lhs && rhs }
> > 
> > let truthyValue = true and false
> 
> +1 (i like your thinking, even if it is unlikely to happen in swift)
> 
> (noteworthy, your example used "RIGHTWARDS ARROW" (U+2192) instead of ->, 
> whether on purpose or not.)
> 
> speaking of &&, was it just a copy-paste from C or is there a more 
> fundamental reason to use that instead of &? in C they had to use two 
> different operators because of the implicit int <-> bool promotions, but in 
> swift "true & false" vs "1 & 2" would have been distinguishable.

The difference between the & and && operators isn't to do with the implicit 
conversions; it's to do with whether both sides of the expression are evaluated 
or not.

false && system('rm -rf')

You really don't want to do that if both sides are executed ...

Alex

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

Re: [swift-evolution] Swift and actors

[Mike Kluev via swift-evolution]

on Wed, 4 Oct 2017 00:16:14 +0200 Benjamin Garrigues <
benjamin.garrig...@gmail.com> wrote:

> Same goes for actors and blocking calls : if you're dealing with a few
coarsed
> grained actors that handle a large state and communicate over an
unreliable
> medium ( such as a network) , you're going to have a very different need
than
> if all your actors run on the same cpu and each handle a very small part
of
> your logic and data. In the second case you're using actors for thread
safety
> and not really to manage failure or lag in actor to actor communications.

exactly my thoughts. unreliably UDP-style "best effort" delivery approach
which
is at the core of actors and "thread safety problems and their solutions on
a single
or multi core CPU box" are two different tasks at hand IMHO. unless i
misunderstand something fundamental here, which is of course possible.

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

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

[Mike Kluev via swift-evolution]

on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong 
  wrote:

> Because, ideally, I’d love to be able to do:
>
> infix operator and: LogicalConjunctionPrecedence // or whatever the
precedence is called
> func and(lhs: Bool, rhs: Bool) → Bool { return lhs && rhs }
>
> let truthyValue = true and false

+1 (i like your thinking, even if it is unlikely to happen in swift)

(noteworthy, your example used "RIGHTWARDS ARROW" (U+2192) instead of ->,
whether on purpose or not.)

speaking of &&, was it just a copy-paste from C or is there a more
fundamental reason to use that instead of &? in C they had to use two
different operators because of the implicit int <-> bool promotions, but in
swift "true & false" vs "1 & 2" would have been distinguishable.

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

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

[Xiaodi Wu via swift-evolution]

On Wed, Oct 4, 2017 at 04:55 Xiaodi Wu  wrote:

> Seems like the API would be actively hiding he possibility of failure so
> that you’d have to be in the know to prevent it. Those who don’t know about
> it would be hunting down a ghost as they’re trying to debug, especially if
> their program crashes rarely, stochastically, and non-reproducibly because
> a third party library calls random() in code they can’t see. I think this
> makes trapping the least acceptable of all options.


I agree with Felix’s concern, which is why I brought up the question, but
ultimately the issue is unavoidable. It’s not down to global instance or
not. If your source of random numbers is unseedable and may mix in
additional entropy at any time, then it may fail at any time because when a
hardware restart might happen may be transparent to the process. The user
must know about this or else we are laying a trap (pun intended).

On Wed, Oct 4, 2017 at 04:49 Jonathan Hull  wrote:
>
>> @Xiaodi:  What do you think of the possibility of trapping in cases of
>> low entropy, and adding an additional global function that checks for
>> entropy so that conscientious programmers can avoid the trap and provide an
>> alternative (or error message)?
>>
>> Thanks,
>> Jon
>>
>>
>> On Oct 4, 2017, at 2:41 AM, Xiaodi Wu  wrote:
>>
>>
>> On Wed, Oct 4, 2017 at 02:39 Félix Cloutier 
>> wrote:
>>
>>> I'm really not enthusiastic about `random() -> Self?` or `random()
>>> throws -> Self` when the only possible error is that some global object
>>> hasn't been initialized.
>>>
>>> The idea of having `random` straight on integers and floats and
>>> collections was to provide a simple interface, but using a global CSPRNG
>>> for those operations comes at a significant usability cost. I think that
>>> something has to go:
>>>
>>>
>>>1. Drop the random methods on FixedWidthInteger, FloatingPoint
>>>   - ...or drop the CSPRNG as a default
>>>2. Drop the optional/throws, and trap on error
>>>
>>>
>>> I know I wouldn't use the `Int.random()` method if I had to unwrap every
>>> single result, when getting one non-nil result guarantees that the program
>>> won't see any other nil result again until it restarts.
>>>
>>
>> From the perspective of an app that can be suspended and resumed at any
>> time, “until it restarts” could be as soon as the next invocation of
>> `Int.random()`, could it not?
>>
>>
>>> Félix
>>>
>>> Le 3 oct. 2017 à 23:44, Jonathan Hull  a écrit :
>>>
>>> I like the idea of splitting it into 2 separate “Random” proposals.
>>>
>>> The first would have Xiaodi’s built-in CSPRNG which only has the
>>> interface:
>>>
>>> On FixedWidthInteger:
>>> static func random()throws -> Self
>>> static func random(in range: ClosedRange)throws -> Self
>>>
>>> On Double:
>>> static func random()throws -> Double
>>> static func random(in range: ClosedRange)throws -> Double
>>>
>>> (Everything else we want, like shuffled(), could be built in later
>>> proposals by calling those functions)
>>>
>>> The other option would be to remove the ‘throws’ from the above
>>> functions (perhaps fatalError-ing), and provide an additional function
>>> which can be used to check that there is enough entropy (so as to avoid the
>>> crash or fall back to a worse source when the CSPRNG is unavailable).
>>>
>>>
>>>
>>> Then a second proposal would bring in the concept of RandomSources
>>> (whatever we call them), which can return however many random bytes you ask
>>> for… and a protocol for types which know how to initialize themselves from
>>> those bytes.  That might be spelled like 'static func random(using:
>>> RandomSource)->Self'.  As a convenience, the source would also be able to
>>> create FixedWidthIntegers and Doubles (both with and without a range), and
>>> would also have the coinFlip() and oneIn(UInt)->Bool functions. Most types
>>> should be able to build themselves off of that.  There would be a default
>>> source which is built from the first protocol.
>>>
>>> I also really think we should have a concept of Repeatably-Random as a
>>> subprotocol for the second proposal.  I see far too many shipping apps
>>> which have bugs due to using arc4Random when they really needed a
>>> repeatable source (e.g. patterns and lines jump around when you resize
>>> things). If it was an easy option, people would use it when appropriate.
>>> This would just mean a sub-protocol which has an initializer which takes a
>>> seed, and the ability to save/restore state (similar to CGContexts).
>>>
>>> The second proposal would also include things like shuffled() and
>>> shuffled(using:).
>>>
>>> Thanks,
>>> Jon
>>>
>>>
>>>
>>> On Oct 3, 2017, at 9:31 PM, Alejandro Alonso 
>>> wrote:
>>>
>>> I really like the schedule here. After reading for a while, I do agree
>>> with Brent that stdlib should very primitive in functionality that it
>>> provides. I also 

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

[Jonathan Hull via swift-evolution]

What about the opposite then, where we internally switch to a slightly less 
random source, but keep the extra function so conscientious programmers can 
check/handle cases where there isn’t enough entropy specially if needed?

Thanks,
Jon


> On Oct 4, 2017, at 2:55 AM, Xiaodi Wu  wrote:
> 
> Seems like the API would be actively hiding he possibility of failure so that 
> you’d have to be in the know to prevent it. Those who don’t know about it 
> would be hunting down a ghost as they’re trying to debug, especially if their 
> program crashes rarely, stochastically, and non-reproducibly because a third 
> party library calls random() in code they can’t see. I think this makes 
> trapping the least acceptable of all options.
> On Wed, Oct 4, 2017 at 04:49 Jonathan Hull  > wrote:
> @Xiaodi:  What do you think of the possibility of trapping in cases of low 
> entropy, and adding an additional global function that checks for entropy so 
> that conscientious programmers can avoid the trap and provide an alternative 
> (or error message)?
> 
> Thanks,
> Jon
> 
> 
>> On Oct 4, 2017, at 2:41 AM, Xiaodi Wu > > wrote:
>> 
>> 
>> On Wed, Oct 4, 2017 at 02:39 Félix Cloutier > > wrote:
>> I'm really not enthusiastic about `random() -> Self?` or `random() throws -> 
>> Self` when the only possible error is that some global object hasn't been 
>> initialized.
>> 
>> The idea of having `random` straight on integers and floats and collections 
>> was to provide a simple interface, but using a global CSPRNG for those 
>> operations comes at a significant usability cost. I think that something has 
>> to go:
>> 
>> Drop the random methods on FixedWidthInteger, FloatingPoint
>> ...or drop the CSPRNG as a default
>> Drop the optional/throws, and trap on error
>> 
>> I know I wouldn't use the `Int.random()` method if I had to unwrap every 
>> single result, when getting one non-nil result guarantees that the program 
>> won't see any other nil result again until it restarts.
>> 
>> From the perspective of an app that can be suspended and resumed at any 
>> time, “until it restarts” could be as soon as the next invocation of 
>> `Int.random()`, could it not?
>> 
>> 
>> Félix
>> 
>>> Le 3 oct. 2017 à 23:44, Jonathan Hull >> > a écrit :
>>> 
>>> I like the idea of splitting it into 2 separate “Random” proposals.
>>> 
>>> The first would have Xiaodi’s built-in CSPRNG which only has the interface:
>>> 
>>> On FixedWidthInteger:
>>> static func random()throws -> Self
>>> static func random(in range: ClosedRange)throws -> Self
>>> 
>>> On Double:
>>> static func random()throws -> Double
>>> static func random(in range: ClosedRange)throws -> Double
>>> 
>>> (Everything else we want, like shuffled(), could be built in later 
>>> proposals by calling those functions)
>>> 
>>> The other option would be to remove the ‘throws’ from the above functions 
>>> (perhaps fatalError-ing), and provide an additional function which can be 
>>> used to check that there is enough entropy (so as to avoid the crash or 
>>> fall back to a worse source when the CSPRNG is unavailable).
>>> 
>>> 
>>> 
>>> Then a second proposal would bring in the concept of RandomSources 
>>> (whatever we call them), which can return however many random bytes you ask 
>>> for… and a protocol for types which know how to initialize themselves from 
>>> those bytes.  That might be spelled like 'static func random(using: 
>>> RandomSource)->Self'.  As a convenience, the source would also be able to 
>>> create FixedWidthIntegers and Doubles (both with and without a range), and 
>>> would also have the coinFlip() and oneIn(UInt)->Bool functions. Most types 
>>> should be able to build themselves off of that.  There would be a default 
>>> source which is built from the first protocol.
>>> 
>>> I also really think we should have a concept of Repeatably-Random as a 
>>> subprotocol for the second proposal.  I see far too many shipping apps 
>>> which have bugs due to using arc4Random when they really needed a 
>>> repeatable source (e.g. patterns and lines jump around when you resize 
>>> things). If it was an easy option, people would use it when appropriate. 
>>> This would just mean a sub-protocol which has an initializer which takes a 
>>> seed, and the ability to save/restore state (similar to CGContexts).
>>> 
>>> The second proposal would also include things like shuffled() and 
>>> shuffled(using:).
>>> 
>>> Thanks,
>>> Jon
>>> 
>>> 
>>> 
 On Oct 3, 2017, at 9:31 PM, Alejandro Alonso > wrote:
 
 I really like the schedule here. After reading for a while, I do agree 
 with Brent that stdlib should very primitive in functionality that it 
 provides. I also agree that 

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

[Xiaodi Wu via swift-evolution]

Seems like the API would be actively hiding he possibility of failure so
that you’d have to be in the know to prevent it. Those who don’t know about
it would be hunting down a ghost as they’re trying to debug, especially if
their program crashes rarely, stochastically, and non-reproducibly because
a third party library calls random() in code they can’t see. I think this
makes trapping the least acceptable of all options.
On Wed, Oct 4, 2017 at 04:49 Jonathan Hull  wrote:

> @Xiaodi:  What do you think of the possibility of trapping in cases of low
> entropy, and adding an additional global function that checks for entropy
> so that conscientious programmers can avoid the trap and provide an
> alternative (or error message)?
>
> Thanks,
> Jon
>
>
> On Oct 4, 2017, at 2:41 AM, Xiaodi Wu  wrote:
>
>
> On Wed, Oct 4, 2017 at 02:39 Félix Cloutier 
> wrote:
>
>> I'm really not enthusiastic about `random() -> Self?` or `random() throws
>> -> Self` when the only possible error is that some global object hasn't
>> been initialized.
>>
>> The idea of having `random` straight on integers and floats and
>> collections was to provide a simple interface, but using a global CSPRNG
>> for those operations comes at a significant usability cost. I think that
>> something has to go:
>>
>>
>>1. Drop the random methods on FixedWidthInteger, FloatingPoint
>>   - ...or drop the CSPRNG as a default
>>2. Drop the optional/throws, and trap on error
>>
>>
>> I know I wouldn't use the `Int.random()` method if I had to unwrap every
>> single result, when getting one non-nil result guarantees that the program
>> won't see any other nil result again until it restarts.
>>
>
> From the perspective of an app that can be suspended and resumed at any
> time, “until it restarts” could be as soon as the next invocation of
> `Int.random()`, could it not?
>
>
>> Félix
>>
>> Le 3 oct. 2017 à 23:44, Jonathan Hull  a écrit :
>>
>> I like the idea of splitting it into 2 separate “Random” proposals.
>>
>> The first would have Xiaodi’s built-in CSPRNG which only has the
>> interface:
>>
>> On FixedWidthInteger:
>> static func random()throws -> Self
>> static func random(in range: ClosedRange)throws -> Self
>>
>> On Double:
>> static func random()throws -> Double
>> static func random(in range: ClosedRange)throws -> Double
>>
>> (Everything else we want, like shuffled(), could be built in later
>> proposals by calling those functions)
>>
>> The other option would be to remove the ‘throws’ from the above functions
>> (perhaps fatalError-ing), and provide an additional function which can be
>> used to check that there is enough entropy (so as to avoid the crash or
>> fall back to a worse source when the CSPRNG is unavailable).
>>
>>
>>
>> Then a second proposal would bring in the concept of RandomSources
>> (whatever we call them), which can return however many random bytes you ask
>> for… and a protocol for types which know how to initialize themselves from
>> those bytes.  That might be spelled like 'static func random(using:
>> RandomSource)->Self'.  As a convenience, the source would also be able to
>> create FixedWidthIntegers and Doubles (both with and without a range), and
>> would also have the coinFlip() and oneIn(UInt)->Bool functions. Most types
>> should be able to build themselves off of that.  There would be a default
>> source which is built from the first protocol.
>>
>> I also really think we should have a concept of Repeatably-Random as a
>> subprotocol for the second proposal.  I see far too many shipping apps
>> which have bugs due to using arc4Random when they really needed a
>> repeatable source (e.g. patterns and lines jump around when you resize
>> things). If it was an easy option, people would use it when appropriate.
>> This would just mean a sub-protocol which has an initializer which takes a
>> seed, and the ability to save/restore state (similar to CGContexts).
>>
>> The second proposal would also include things like shuffled() and
>> shuffled(using:).
>>
>> Thanks,
>> Jon
>>
>>
>>
>> On Oct 3, 2017, at 9:31 PM, Alejandro Alonso 
>> wrote:
>>
>> I really like the schedule here. After reading for a while, I do agree
>> with Brent that stdlib should very primitive in functionality that it
>> provides. I also agree that the most important part right now is designing
>> the internal crypto on which the numeric types use to return their
>> respected random number. On the discussion of how we should handle not
>> enough entropy with the device random, from a users perspective it makes
>> sense that calling .random should just give me a random number, but from a
>> developers perspective I see Optional being the best choice here. While I
>> think blocking could, in most cases, provide the user an easier API, we
>> have to do this right and be safe here by providing a value that indicates
>> that there is room for 

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

[Jonathan Hull via swift-evolution]

@Xiaodi:  What do you think of the possibility of trapping in cases of low 
entropy, and adding an additional global function that checks for entropy so 
that conscientious programmers can avoid the trap and provide an alternative 
(or error message)?

Thanks,
Jon

> On Oct 4, 2017, at 2:41 AM, Xiaodi Wu  wrote:
> 
> 
> On Wed, Oct 4, 2017 at 02:39 Félix Cloutier  > wrote:
> I'm really not enthusiastic about `random() -> Self?` or `random() throws -> 
> Self` when the only possible error is that some global object hasn't been 
> initialized.
> 
> The idea of having `random` straight on integers and floats and collections 
> was to provide a simple interface, but using a global CSPRNG for those 
> operations comes at a significant usability cost. I think that something has 
> to go:
> 
> Drop the random methods on FixedWidthInteger, FloatingPoint
> ...or drop the CSPRNG as a default
> Drop the optional/throws, and trap on error
> 
> I know I wouldn't use the `Int.random()` method if I had to unwrap every 
> single result, when getting one non-nil result guarantees that the program 
> won't see any other nil result again until it restarts.
> 
> From the perspective of an app that can be suspended and resumed at any time, 
> “until it restarts” could be as soon as the next invocation of 
> `Int.random()`, could it not?
> 
> 
> Félix
> 
>> Le 3 oct. 2017 à 23:44, Jonathan Hull > > a écrit :
>> 
>> I like the idea of splitting it into 2 separate “Random” proposals.
>> 
>> The first would have Xiaodi’s built-in CSPRNG which only has the interface:
>> 
>> On FixedWidthInteger:
>>  static func random()throws -> Self
>>  static func random(in range: ClosedRange)throws -> Self
>> 
>> On Double:
>>  static func random()throws -> Double
>>  static func random(in range: ClosedRange)throws -> Double
>> 
>> (Everything else we want, like shuffled(), could be built in later proposals 
>> by calling those functions)
>> 
>> The other option would be to remove the ‘throws’ from the above functions 
>> (perhaps fatalError-ing), and provide an additional function which can be 
>> used to check that there is enough entropy (so as to avoid the crash or fall 
>> back to a worse source when the CSPRNG is unavailable).
>> 
>> 
>> 
>> Then a second proposal would bring in the concept of RandomSources (whatever 
>> we call them), which can return however many random bytes you ask for… and a 
>> protocol for types which know how to initialize themselves from those bytes. 
>>  That might be spelled like 'static func random(using: RandomSource)->Self'. 
>>  As a convenience, the source would also be able to create 
>> FixedWidthIntegers and Doubles (both with and without a range), and would 
>> also have the coinFlip() and oneIn(UInt)->Bool functions. Most types should 
>> be able to build themselves off of that.  There would be a default source 
>> which is built from the first protocol.
>> 
>> I also really think we should have a concept of Repeatably-Random as a 
>> subprotocol for the second proposal.  I see far too many shipping apps which 
>> have bugs due to using arc4Random when they really needed a repeatable 
>> source (e.g. patterns and lines jump around when you resize things). If it 
>> was an easy option, people would use it when appropriate. This would just 
>> mean a sub-protocol which has an initializer which takes a seed, and the 
>> ability to save/restore state (similar to CGContexts).
>> 
>> The second proposal would also include things like shuffled() and 
>> shuffled(using:).
>> 
>> Thanks,
>> Jon
>> 
>> 
>> 
>>> On Oct 3, 2017, at 9:31 PM, Alejandro Alonso >> > wrote:
>>> 
>>> I really like the schedule here. After reading for a while, I do agree with 
>>> Brent that stdlib should very primitive in functionality that it provides. 
>>> I also agree that the most important part right now is designing the 
>>> internal crypto on which the numeric types use to return their respected 
>>> random number. On the discussion of how we should handle not enough entropy 
>>> with the device random, from a users perspective it makes sense that 
>>> calling .random should just give me a random number, but from a developers 
>>> perspective I see Optional being the best choice here. While I think 
>>> blocking could, in most cases, provide the user an easier API, we have to 
>>> do this right and be safe here by providing a value that indicates that 
>>> there is room for error here. As for the generator abstraction, I believe 
>>> there should be a bare basic protocol that sets a layout for new generators 
>>> and should be focusing on its requirements. 
>>> 
>>> Whether or not RandomAccessCollection and MutableCollection should get 
>>> .random and .shuffle/.shuffled in this first proposal is completely up in 
>>> the air for me. It 

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

[Xiaodi Wu via swift-evolution]

On Wed, Oct 4, 2017 at 02:39 Félix Cloutier 
wrote:

> I'm really not enthusiastic about `random() -> Self?` or `random() throws
> -> Self` when the only possible error is that some global object hasn't
> been initialized.
>
> The idea of having `random` straight on integers and floats and
> collections was to provide a simple interface, but using a global CSPRNG
> for those operations comes at a significant usability cost. I think that
> something has to go:
>
>
>1. Drop the random methods on FixedWidthInteger, FloatingPoint
>   - ...or drop the CSPRNG as a default
>2. Drop the optional/throws, and trap on error
>
>
> I know I wouldn't use the `Int.random()` method if I had to unwrap every
> single result, when getting one non-nil result guarantees that the program
> won't see any other nil result again until it restarts.
>

>From the perspective of an app that can be suspended and resumed at any
time, “until it restarts” could be as soon as the next invocation of
`Int.random()`, could it not?


> Félix
>
> Le 3 oct. 2017 à 23:44, Jonathan Hull  a écrit :
>
> I like the idea of splitting it into 2 separate “Random” proposals.
>
> The first would have Xiaodi’s built-in CSPRNG which only has the interface:
>
> On FixedWidthInteger:
> static func random()throws -> Self
> static func random(in range: ClosedRange)throws -> Self
>
> On Double:
> static func random()throws -> Double
> static func random(in range: ClosedRange)throws -> Double
>
> (Everything else we want, like shuffled(), could be built in later
> proposals by calling those functions)
>
> The other option would be to remove the ‘throws’ from the above functions
> (perhaps fatalError-ing), and provide an additional function which can be
> used to check that there is enough entropy (so as to avoid the crash or
> fall back to a worse source when the CSPRNG is unavailable).
>
>
>
> Then a second proposal would bring in the concept of RandomSources
> (whatever we call them), which can return however many random bytes you ask
> for… and a protocol for types which know how to initialize themselves from
> those bytes.  That might be spelled like 'static func random(using:
> RandomSource)->Self'.  As a convenience, the source would also be able to
> create FixedWidthIntegers and Doubles (both with and without a range), and
> would also have the coinFlip() and oneIn(UInt)->Bool functions. Most types
> should be able to build themselves off of that.  There would be a default
> source which is built from the first protocol.
>
> I also really think we should have a concept of Repeatably-Random as a
> subprotocol for the second proposal.  I see far too many shipping apps
> which have bugs due to using arc4Random when they really needed a
> repeatable source (e.g. patterns and lines jump around when you resize
> things). If it was an easy option, people would use it when appropriate.
> This would just mean a sub-protocol which has an initializer which takes a
> seed, and the ability to save/restore state (similar to CGContexts).
>
> The second proposal would also include things like shuffled() and
> shuffled(using:).
>
> Thanks,
> Jon
>
>
>
> On Oct 3, 2017, at 9:31 PM, Alejandro Alonso 
> wrote:
>
> I really like the schedule here. After reading for a while, I do agree
> with Brent that stdlib should very primitive in functionality that it
> provides. I also agree that the most important part right now is designing
> the internal crypto on which the numeric types use to return their
> respected random number. On the discussion of how we should handle not
> enough entropy with the device random, from a users perspective it makes
> sense that calling .random should just give me a random number, but from a
> developers perspective I see Optional being the best choice here. While I
> think blocking could, in most cases, provide the user an easier API, we
> have to do this right and be safe here by providing a value that indicates
> that there is room for error here. As for the generator abstraction, I
> believe there should be a bare basic protocol that sets a layout for new
> generators and should be focusing on its requirements.
>
> Whether or not RandomAccessCollection and MutableCollection should get
> .random and .shuffle/.shuffled in this first proposal is completely up in
> the air for me. It makes sense, to me, to include the .random in this
> proposal and open another one .shuffle/.shuffled, but I can see arguments
> that should say we create something separate for these two, or include all
> of it in this proposal.
>
> - Alejandro
>
> On Sep 27, 2017, 7:29 PM -0500, Xiaodi Wu , wrote:
>
>
> On Wed, Sep 27, 2017 at 00:18 Félix Cloutier 
> wrote:
>
>> Le 26 sept. 2017 à 16:14, Xiaodi Wu  a écrit :
>>
>> On Tue, Sep 26, 2017 at 11:26 AM, Félix Cloutier <
>> felixclout...@icloud.com> wrote:
>>
>>>
>>> It's 

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

[Elia Cereda via swift-evolution]

>> 
>> Anyway, for my use case mentioned earlier (shipping a release version of my 
>> app bundle), that doesn’t really matter. I’d just like a compiler switch 
>> that made the whole module not having an ABI, essentially making all all 
>> methods and types @inlinable and @_versioned, using the terminology in your 
>> example.
> 
> Yes, that would be a nice feature to have but it is outside the scope of this 
> proposal. First, we want to tackle shipping resilient modules — then we can 
> discuss generalizing the notion of a “resilience domain” to encompass 
> multiple modules. I realize the latter is more useful to third party 
> developers though, and I apologize that in this particular case our 
> priorities are at odds…

If a framework is only ever used by a single client in the app bundle, as it is 
in the majority of cases, I think the objective should be to link it 
statically. The dynamic linking overhead is useless in this case. Would this 
allow the compiler to optimize across module boundaries? (Are the current 
capabilities of Xcode 9 in this regard described anywhere?) 

Elia Cereda

> Il giorno 04 ott 2017, alle ore 08:09, Slava Pestov via swift-evolution 
>  ha scritto:
> 
> 
> 
>> On Oct 3, 2017, at 11:05 PM, Jonas B > > wrote:
>> 
>> 
>>> On 4 Oct 2017, at 14:33, Slava Pestov >> > wrote:
>>> 
>>> @_versioned makes a symbol visible externally without making it visible 
>>> from the language. There is no requirement that a @_versioned thing is 
>>> @inlinable. It is used when you want to reference an internal function from 
>>> an inlinable function. Eg,
>>> 
>>> internal func myImplDetail() { … }
>>> 
>>> @inlinable public func myPublicFunction() { myImplDetail() } // error!
>>> 
>>> —
>>> 
>>> @_versioned internal func myImplDetail() { … }
>>> 
>>> @inlinable public func myPublicFunction() { myImplDetail() } // OK
>>> 
>>> Slava
>> 
>> 
>> From my language user point of view it would be more understandable if that 
>> was written with a single keyword, eg:
>> @nonABI internal func myImplDetail() { }
>> @nonABI public func myPublicFunction() { myImplDetail() }  // OK
> 
> The two attributes are different though. myImplDetail() is _not_ inlined into 
> client code here, but myPublicFunction() is. So they need different 
> attributes to express this intent.
> 
>> 
>> Anyway, for my use case mentioned earlier (shipping a release version of my 
>> app bundle), that doesn’t really matter. I’d just like a compiler switch 
>> that made the whole module not having an ABI, essentially making all all 
>> methods and types @inlinable and @_versioned, using the terminology in your 
>> example.
> 
> Yes, that would be a nice feature to have but it is outside the scope of this 
> proposal. First, we want to tackle shipping resilient modules — then we can 
> discuss generalizing the notion of a “resilience domain” to encompass 
> multiple modules. I realize the latter is more useful to third party 
> developers though, and I apologize that in this particular case our 
> priorities are at odds…
> 
>> 
>> My other observation is that no matter how great the ergonomics, and no 
>> matter the naming of these attributes, very few people outside the compiler 
>> team is going to be able to successfully ship a versioned library without 
>> the “Checking Binary Compatibility” tool mentioned in 
>> https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#checking-binary-compatibility
>>  
>> .
> 
> I agree — even for members of the compiler team this tool would be very 
> useful, both as a way of encoding our assumptions for sanity-checking, and 
> making sure we don’t make a silly mistake with a future update to the 
> standard library.
> 
> Slava
> 
>> 
>> /Jonas
>> 
> 
> ___
> 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

[Félix Cloutier via swift-evolution]

I'm really not enthusiastic about `random() -> Self?` or `random() throws -> 
Self` when the only possible error is that some global object hasn't been 
initialized.

The idea of having `random` straight on integers and floats and collections was 
to provide a simple interface, but using a global CSPRNG for those operations 
comes at a significant usability cost. I think that something has to go:

Drop the random methods on FixedWidthInteger, FloatingPoint
...or drop the CSPRNG as a default
Drop the optional/throws, and trap on error

I know I wouldn't use the `Int.random()` method if I had to unwrap every single 
result, when getting one non-nil result guarantees that the program won't see 
any other nil result again until it restarts.

Félix

> Le 3 oct. 2017 à 23:44, Jonathan Hull  a écrit :
> 
> I like the idea of splitting it into 2 separate “Random” proposals.
> 
> The first would have Xiaodi’s built-in CSPRNG which only has the interface:
> 
> On FixedWidthInteger:
>   static func random()throws -> Self
>   static func random(in range: ClosedRange)throws -> Self
> 
> On Double:
>   static func random()throws -> Double
>   static func random(in range: ClosedRange)throws -> Double
> 
> (Everything else we want, like shuffled(), could be built in later proposals 
> by calling those functions)
> 
> The other option would be to remove the ‘throws’ from the above functions 
> (perhaps fatalError-ing), and provide an additional function which can be 
> used to check that there is enough entropy (so as to avoid the crash or fall 
> back to a worse source when the CSPRNG is unavailable).
> 
> 
> 
> Then a second proposal would bring in the concept of RandomSources (whatever 
> we call them), which can return however many random bytes you ask for… and a 
> protocol for types which know how to initialize themselves from those bytes.  
> That might be spelled like 'static func random(using: RandomSource)->Self'.  
> As a convenience, the source would also be able to create FixedWidthIntegers 
> and Doubles (both with and without a range), and would also have the 
> coinFlip() and oneIn(UInt)->Bool functions. Most types should be able to 
> build themselves off of that.  There would be a default source which is built 
> from the first protocol.
> 
> I also really think we should have a concept of Repeatably-Random as a 
> subprotocol for the second proposal.  I see far too many shipping apps which 
> have bugs due to using arc4Random when they really needed a repeatable source 
> (e.g. patterns and lines jump around when you resize things). If it was an 
> easy option, people would use it when appropriate. This would just mean a 
> sub-protocol which has an initializer which takes a seed, and the ability to 
> save/restore state (similar to CGContexts).
> 
> The second proposal would also include things like shuffled() and 
> shuffled(using:).
> 
> Thanks,
> Jon
> 
> 
> 
>> On Oct 3, 2017, at 9:31 PM, Alejandro Alonso > > wrote:
>> 
>> I really like the schedule here. After reading for a while, I do agree with 
>> Brent that stdlib should very primitive in functionality that it provides. I 
>> also agree that the most important part right now is designing the internal 
>> crypto on which the numeric types use to return their respected random 
>> number. On the discussion of how we should handle not enough entropy with 
>> the device random, from a users perspective it makes sense that calling 
>> .random should just give me a random number, but from a developers 
>> perspective I see Optional being the best choice here. While I think 
>> blocking could, in most cases, provide the user an easier API, we have to do 
>> this right and be safe here by providing a value that indicates that there 
>> is room for error here. As for the generator abstraction, I believe there 
>> should be a bare basic protocol that sets a layout for new generators and 
>> should be focusing on its requirements. 
>> 
>> Whether or not RandomAccessCollection and MutableCollection should get 
>> .random and .shuffle/.shuffled in this first proposal is completely up in 
>> the air for me. It makes sense, to me, to include the .random in this 
>> proposal and open another one .shuffle/.shuffled, but I can see arguments 
>> that should say we create something separate for these two, or include all 
>> of it in this proposal.
>> 
>> - Alejandro
>> 
>> On Sep 27, 2017, 7:29 PM -0500, Xiaodi Wu > >, wrote:
>>> 
>>> On Wed, Sep 27, 2017 at 00:18 Félix Cloutier >> > wrote:
 Le 26 sept. 2017 à 16:14, Xiaodi Wu > a écrit :
 
>>> 
 On Tue, Sep 26, 2017 at 11:26 AM, Félix Cloutier > wrote:
 
 It's possible to use a 

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

[Jonathan Hull via swift-evolution]

I like the idea of splitting it into 2 separate “Random” proposals.

The first would have Xiaodi’s built-in CSPRNG which only has the interface:

On FixedWidthInteger:
static func random()throws -> Self
static func random(in range: ClosedRange)throws -> Self

On Double:
static func random()throws -> Double
static func random(in range: ClosedRange)throws -> Double

(Everything else we want, like shuffled(), could be built in later proposals by 
calling those functions)

The other option would be to remove the ‘throws’ from the above functions 
(perhaps fatalError-ing), and provide an additional function which can be used 
to check that there is enough entropy (so as to avoid the crash or fall back to 
a worse source when the CSPRNG is unavailable).



Then a second proposal would bring in the concept of RandomSources (whatever we 
call them), which can return however many random bytes you ask for… and a 
protocol for types which know how to initialize themselves from those bytes.  
That might be spelled like 'static func random(using: RandomSource)->Self'.  As 
a convenience, the source would also be able to create FixedWidthIntegers and 
Doubles (both with and without a range), and would also have the coinFlip() and 
oneIn(UInt)->Bool functions. Most types should be able to build themselves off 
of that.  There would be a default source which is built from the first 
protocol.

I also really think we should have a concept of Repeatably-Random as a 
subprotocol for the second proposal.  I see far too many shipping apps which 
have bugs due to using arc4Random when they really needed a repeatable source 
(e.g. patterns and lines jump around when you resize things). If it was an easy 
option, people would use it when appropriate. This would just mean a 
sub-protocol which has an initializer which takes a seed, and the ability to 
save/restore state (similar to CGContexts).

The second proposal would also include things like shuffled() and 
shuffled(using:).

Thanks,
Jon



> On Oct 3, 2017, at 9:31 PM, Alejandro Alonso  wrote:
> 
> I really like the schedule here. After reading for a while, I do agree with 
> Brent that stdlib should very primitive in functionality that it provides. I 
> also agree that the most important part right now is designing the internal 
> crypto on which the numeric types use to return their respected random 
> number. On the discussion of how we should handle not enough entropy with the 
> device random, from a users perspective it makes sense that calling .random 
> should just give me a random number, but from a developers perspective I see 
> Optional being the best choice here. While I think blocking could, in most 
> cases, provide the user an easier API, we have to do this right and be safe 
> here by providing a value that indicates that there is room for error here. 
> As for the generator abstraction, I believe there should be a bare basic 
> protocol that sets a layout for new generators and should be focusing on its 
> requirements. 
> 
> Whether or not RandomAccessCollection and MutableCollection should get 
> .random and .shuffle/.shuffled in this first proposal is completely up in the 
> air for me. It makes sense, to me, to include the .random in this proposal 
> and open another one .shuffle/.shuffled, but I can see arguments that should 
> say we create something separate for these two, or include all of it in this 
> proposal.
> 
> - Alejandro
> 
> On Sep 27, 2017, 7:29 PM -0500, Xiaodi Wu , wrote:
>> 
>> On Wed, Sep 27, 2017 at 00:18 Félix Cloutier > > wrote:
>>> Le 26 sept. 2017 à 16:14, Xiaodi Wu >> > a écrit :
>>> 
>> 
>>> On Tue, Sep 26, 2017 at 11:26 AM, Félix Cloutier >> > wrote:
>>> 
>>> It's possible to use a CSPRNG-grade algorithm and seed it once to get a 
>>> reproducible sequence, but when you use it as a CSPRNG, you typically feed 
>>> entropy back into it at nondeterministic points to ensure that even if you 
>>> started with a bad seed, you'll eventually get to an alright state. Unless 
>>> you keep track of when entropy was mixed in and what the values were, 
>>> you'll never get a reproducible CSPRNG.
>>> 
>>> We would give developers a false sense of security if we provided them with 
>>> CSPRNG-grade algorithms that we called CSPRNGs and that they could seed 
>>> themselves. Just because it says "crypto-secure" in the name doesn't mean 
>>> that it'll be crypto-secure if it's seeded with time(). Therefore, 
>>> "reproducible" vs "non-reproducible" looks like a good distinction to me.
>>> 
>>> I disagree here, in two respects:
>>> 
>>> First, whether or not a particular PRNG is cryptographically secure is an 
>>> intrinsic property of the algorithm; whether it's "reproducible" or not is 
>>> 

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

[Slava Pestov via swift-evolution]

> On Oct 3, 2017, at 11:05 PM, Jonas B  wrote:
> 
> 
>> On 4 Oct 2017, at 14:33, Slava Pestov > > wrote:
>> 
>> @_versioned makes a symbol visible externally without making it visible from 
>> the language. There is no requirement that a @_versioned thing is 
>> @inlinable. It is used when you want to reference an internal function from 
>> an inlinable function. Eg,
>> 
>> internal func myImplDetail() { … }
>> 
>> @inlinable public func myPublicFunction() { myImplDetail() } // error!
>> 
>> —
>> 
>> @_versioned internal func myImplDetail() { … }
>> 
>> @inlinable public func myPublicFunction() { myImplDetail() } // OK
>> 
>> Slava
> 
> 
> From my language user point of view it would be more understandable if that 
> was written with a single keyword, eg:
> @nonABI internal func myImplDetail() { }
> @nonABI public func myPublicFunction() { myImplDetail() }  // OK

The two attributes are different though. myImplDetail() is _not_ inlined into 
client code here, but myPublicFunction() is. So they need different attributes 
to express this intent.

> 
> Anyway, for my use case mentioned earlier (shipping a release version of my 
> app bundle), that doesn’t really matter. I’d just like a compiler switch that 
> made the whole module not having an ABI, essentially making all all methods 
> and types @inlinable and @_versioned, using the terminology in your example.

Yes, that would be a nice feature to have but it is outside the scope of this 
proposal. First, we want to tackle shipping resilient modules — then we can 
discuss generalizing the notion of a “resilience domain” to encompass multiple 
modules. I realize the latter is more useful to third party developers though, 
and I apologize that in this particular case our priorities are at odds…

> 
> My other observation is that no matter how great the ergonomics, and no 
> matter the naming of these attributes, very few people outside the compiler 
> team is going to be able to successfully ship a versioned library without the 
> “Checking Binary Compatibility” tool mentioned in 
> https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#checking-binary-compatibility
>  
> .

I agree — even for members of the compiler team this tool would be very useful, 
both as a way of encoding our assumptions for sanity-checking, and making sure 
we don’t make a silly mistake with a future update to the standard library.

Slava

> 
> /Jonas
> 

___
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

[Jonas B via swift-evolution]

> On 4 Oct 2017, at 14:33, Slava Pestov  wrote:
> 
> @_versioned makes a symbol visible externally without making it visible from 
> the language. There is no requirement that a @_versioned thing is @inlinable. 
> It is used when you want to reference an internal function from an inlinable 
> function. Eg,
> 
> internal func myImplDetail() { … }
> 
> @inlinable public func myPublicFunction() { myImplDetail() } // error!
> 
> —
> 
> @_versioned internal func myImplDetail() { … }
> 
> @inlinable public func myPublicFunction() { myImplDetail() } // OK
> 
> Slava


>From my language user point of view it would be more understandable if that 
>was written with a single keyword, eg:
@nonABI internal func myImplDetail() { }
@nonABI public func myPublicFunction() { myImplDetail() }  // OK

Anyway, for my use case mentioned earlier (shipping a release version of my app 
bundle), that doesn’t really matter. I’d just like a compiler switch that made 
the whole module not having an ABI, essentially making all all methods and 
types @inlinable and @_versioned, using the terminology in your example.

My other observation is that no matter how great the ergonomics, and no matter 
the naming of these attributes, very few people outside the compiler team is 
going to be able to successfully ship a versioned library without the “Checking 
Binary Compatibility” tool mentioned in 
https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#checking-binary-compatibility
 
.

/Jonas

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