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

[Zach Drayer via swift-evolution]

To throw an idea out into the wild: How about a protocol to define the default 
source fo random on a given platform, with per-platform extensions to provide 
default implementations?

This would allow any eventual proposal to have default arguments for functions— 
or to use within `var`s— without implicitly annotating one (CS)PRNG as the 
de-facto RNG for Swift on all platforms, as well as remove the requirement for 
providing a `shared` singleton on every (CS)PRNG.

I’m imagining something like this (names taken from, or inspired by, Félix’s 
design for consistency within this discussion, I’m not strongly attached to any 
of them):

```swift
protocol StandardRandomSource {
static var generator: RandomSource { get }
}

extension StandardRandomSource {
static var generator: RandomSource {
#if os(Linux)
// /dev/random chosen naively
return DeviceRandom.shared
#elseif os(macOS) || os(iOS) || os(watchOS) || os(tvOS)
// SecCopyRandomBytes-based, also chosen naively
return SecRandomSource()
#else
fatalError("Standard source of randomness not provided on 
current platform")
#endif
}
}
```

and this new protocol could be used like this (largely copied from Félix’s 
design):

```swift
extension Randomizable {
public static var random: Self {
return random(using: StandardRandomSource.generator)
}
}

extension FixedWidthInteger: {
public static func random(using source: RandomSource = 
StandardRandomSource.generator) -> Self {
return (0 ..< Self.max).random(using: source)
}
}
```

On a more meta level, introducing this protocol lets us (Swift Evolution) kick 
the question of “What (CS)PRNG gets implemented for a given OS as the default 
provider?” further down the road instead of potentially blocking discussion for 
a long time.

Another possible upside that I can think of is: We could let per-platform 
implementations of this protocol could happen outside of the Swift Evolution 
process. Hopefully this means it would be easier to amend or fix in the future, 
as new platforms are added and new best practices arise.

A downside to this idea is that we’d be adding a protocol to the stdlib that 
isn’t intended for people to implement, although there’s no possible harm if 
anyone does so.

One other idea I also explored, but ultimately decided against was having 
per-platform `typealias`es instead of a protocol with a default implementation. 
Without a way to get an instance of a random number generator, I fell back to 
requiring `var shared: Self` to stay in `RandomSource`, which didn’t seem as 
necessary.

-z

> On Sep 25, 2017, at 9:57 PM, Alejandro Alonso via swift-evolution 
>  wrote:
> 
> Hello evolution,
> 
> I am very thankful for all the feedback, and I’ve been working on a design 
> that tries to utilize everybody’s ideas. The link to what I have so far is 
> here: https://gist.github.com/Azoy/15f0518df38df9b722d4cb17bafea4c1. Please 
> keep in mind this is just a design, no actual implementation as I would most 
> likely need assistance in doing. The default source for randomness will use 
> the OS’s unseeded CSPRNG. This current setup exposes developers to an API 
> that lets them create  their own RandomSources on the fly. I want to make the 
> distinction that any existing or new sources of randomness that conform to 
> UnsafeRandomSource are to be considered non cryptographically secure.
> 
> I would love to get this discussion flowing again, and I would love input on 
> the design. A few things I came across with this design is that some may want 
> to use ranges as an argument for the numeric types, RandomAccessCollection 
> returning an optional when getting a random, and how to incorporate an API 
> that allows distributions. I wanted to get input on how you feel about each 
> of these topics as I’m indifferent about them all. I’m in no way saying this 
> is the design we should go for, but I’m simply providing something I think we 
> should build on or talk about.
> 
> - Alejandro
> 
>> On Sep 8, 2017, 11:52 AM -0500, Alejandro Alonso via swift-evolution 
>> , wrote:
>> Hello swift evolution, I would like to propose a unified approach to 
>> `random()` in Swift. I have a simple implementation here 
>> https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5. This 
>> implementation is a simple wrapper over existing random functions so 
>> existing code bases will not be affected. Also, this approach introduces a 
>> new random feature for Linux users that give them access to upper bounds, as 
>> well as a lower bound for both Glibc and Darwin users. This change would be 
>> implemented within Foundation.
>> 
>> I believe this simple change could have a very positive impact on new 
>> developers learning Swift and experienced developers being able to write 
>> single random declarations.
>> 
>> I’d like to hear about your ideas on 

Re: [swift-evolution] [Discussion] mailing list alternative

[Zach Drayer via swift-evolution]

hi

sorry about this message just now, i realize the tone comes across a bit short 
to say the least. buttons were mashed incorrectly and far too soon.

again, my apologies.

-z

(sent from my phone) 

> On Feb 2, 2017, at 8:12 PM, Zach Drayer  wrote:
> 
> 
> 
> 
> 
> (sent from my phone)
> 
>> On Feb 2, 2017, at 3:15 PM, James Berry via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Feb 2, 2017, at 2:44 PM, Nevin Brackett-Rozinsky via swift-evolution 
>>>  wrote:
>>> 
>>> Where do you propose to hold and publicize such a vote in order that the 
>>> people who would participate on a forum but not on a mailing list―ie. those 
>>> for whom the switch will be most beneficial―are enfranchised?
>> 
>> The traditional method on a list like this is +1 or -1 in response to a 
>> given thread. (Note that I’m not calling for such a vote, as I have nothing 
>> to propose). A perhaps more modern approach would be to give a link to an 
>> external site that would run the vote/poll.
>> 
>> As to your question of how to reach an audience larger than what we have now 
>> for a vote, I don’t see any obvious solution: the current community is what 
>> it is. And I would argue that the current community has invested the most 
>> time into the project (and likely will going forward) and should have the 
>> largest vote for how project communication should be facilitated.
> I don't know if the idea that knowing how to use/being comfortable with using 
> a mailing list somehow means your input more valuable than that of someone 
> else is one that I'm comfortable with.
> 
>> I wouldn’t advocate for advertising far and wide over the internet “how 
>> should the swift-evolution community communicate?”, as this would be a vote 
>> of the internet, and not of the swift-evolution community.
> The entire purpose of this discussion is about how best to open 
> swift-evolution up to more people. Why would we ignore input from people who 
> may otherwise be involved?
> 
> 
>> I do admit you could argue the community may have already self-selected to 
>> some degree based on the current method of commutation; I see no real 
>> solution to that apart from continued advocacy from people such as you who 
>> are speaking up to bring awareness about the issues you feel are keeping 
>> outsiders from participating.
> We could try asking people in some non-mailing-list fashion?
> 
> -z
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

[Zach Drayer via swift-evolution]

(sent from my phone)

> On Feb 2, 2017, at 3:15 PM, James Berry via swift-evolution 
>  wrote:
> 
> 
>> On Feb 2, 2017, at 2:44 PM, Nevin Brackett-Rozinsky via swift-evolution 
>>  wrote:
>> 
>> Where do you propose to hold and publicize such a vote in order that the 
>> people who would participate on a forum but not on a mailing list―ie. those 
>> for whom the switch will be most beneficial―are enfranchised?
> 
> The traditional method on a list like this is +1 or -1 in response to a given 
> thread. (Note that I’m not calling for such a vote, as I have nothing to 
> propose). A perhaps more modern approach would be to give a link to an 
> external site that would run the vote/poll.
> 
> As to your question of how to reach an audience larger than what we have now 
> for a vote, I don’t see any obvious solution: the current community is what 
> it is. And I would argue that the current community has invested the most 
> time into the project (and likely will going forward) and should have the 
> largest vote for how project communication should be facilitated.
I don't know if the idea that knowing how to use/being comfortable with using a 
mailing list somehow means your input more valuable than that of someone else 
is one that I'm comfortable with.

> I wouldn’t advocate for advertising far and wide over the internet “how 
> should the swift-evolution community communicate?”, as this would be a vote 
> of the internet, and not of the swift-evolution community.
The entire purpose of this discussion is about how best to open swift-evolution 
up to more people. Why would we ignore input from people who may otherwise be 
involved?


> I do admit you could argue the community may have already self-selected to 
> some degree based on the current method of commutation; I see no real 
> solution to that apart from continued advocacy from people such as you who 
> are speaking up to bring awareness about the issues you feel are keeping 
> outsiders from participating.
We could try asking people in some non-mailing-list fashion?

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

Re: [swift-evolution] [Discussion] mailing list alternative

[Zach Drayer via swift-evolution]

Anything that encourages people to participate is a good thing in my book. 
Mailing lists are nice, but also not a thing many people are comfortable with.

A system that better supports threads means there is less of a cost to people 
having a back-and-forth than there is today, which also seems to be hugely 
beneficial (whether it be letting people hammer out ideas without disturbing 
everyone, or asking a question about something without pulling attention away 
from the main topic at hand).

I understand that there’s only so much bandwidth to go around, that the team 
may like to focus energies elsewhere (and maybe that technical problems are 
easier to solve than social ones), but use of a mailing list has been a topic 
that the community has been bringing up since the very beginning (the earliest 
thread I can find is from a few days after the list was announced: titled 
“Mailman?”, and from Dec 10, 2015; 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
 
).
 Since then, we’ve had a number of Swift proposals, manifestos, and releases 
(not the least of which is Swift 3, which was a tremendous amount of amazing 
work).

Managing communities is definitely hard work, and I really do appreciate how 
much energy everyone already puts into this  —  especially when it’s not 
necessarily a core part of anyone's job. That said, it really would be great if 
some attention could be given to how the community itself works, to come up 
with new ways to let people be involved and to double check that the processes 
we’ve been using are good to go for the next year (for example: I’m still not 
sure of the correct way to revisit an enhancement is after it’s acceptance and 
implementation, and some enhancements like `fileprivate` warrant revisiting).

Thanks,
-z___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution