[Proposal] Random Unification

every now and then i found myself in a situation i want to use this
preferred way, and i need a label... but i do not have anything to pass,
e.g.:

let x = Int(random) // oops

has to resort to hacks: let x = Int(random: ())
or make it a non-initialiser: let x = Int.random or Int.random()

have you guys considered: func random<T>(...) -> T
where it returns a different type based on a context?

Mike

···

On 7 Oct 2017, at 04:24, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

>
>> These aren’t the forms I was suggesting, what I meant was:
>
> extension Int {
> init(randomInRange: Countable{Closed}Range<Int>)
> }
>
> which gives:
> let x = Int(randomInRange: 0..<5)
>
> The point of this is that you’re producing an Int (or whatever type).
Regardless of whether the initializer is failable or not, this is the
preferred way of creating a new value with some property: it is an
initializer with a label.

>
>> These aren’t the forms I was suggesting, what I meant was:
>
> extension Int {
> init(randomInRange: Countable{Closed}Range<Int>)
> }
>
> which gives:
> let x = Int(randomInRange: 0..<5)
>
> The point of this is that you’re producing an Int (or whatever type).
Regardless of whether the initializer is failable or not, this is the
preferred way of creating a new value with some property: it is an
initializer with a label.

or make it a non-initialiser: let x = Int.random or Int.random()

on the positive side would be ability to omit types in many cases:

foo(_ x: Int) { ... }

foo(.random) // Int.random inferred

have you guys considered: func random<T>(...) -> T
where it returns a different type based on a context?

or "foo(random())" here, random<Int>() inferred

the latter case opens wide opportunities for strict type/range checking,
e.g.:

if "angle" is a variable ranging from 0 .. 2*pi then

angle = random() // is inferred as a 0 .. 2*pi range without me typing
anything

Mike

···

On 11 October 2017 at 18:30, Mike Kluev <mike.kluev@gmail.com> wrote:

> On 7 Oct 2017, at 04:24, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:

interesting view point.

FTM, the arithmetic operations in swift are "safe and slow" by default,
same principle...
although they are not that slow (compared to how secure random numbers can
be).

Mike

···

On Wed Oct 11 12:21:14 CDT 2017 Cory Benfield cbenfield at apple.com wrote:

I strongly recommend building the padded room.