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

[Xiaodi Wu via swift-evolution]

On Wed, Nov 22, 2017 at 23:01 Alejandro Alonso 
wrote:

> Like I’ve said, python has different syntax grammar. We have to read each
> call site and form a sentence from it. `random.choice([1, 2, 3])` to me
> this reads, “Get a random choice from array”. This makes sense. Slapping
> the word choice as an instance property like `[1, 2, 3].choice` reads,
> “From array, get choice”. What is choice? This doesn’t make sense at all to
> me. To me, the only good solution is `[1, 2, 3].random` which reads, “From
> array, get random”. I actually think most users will be able to understand
> this at first glance rather than choice (or any or some).
>

Again, my concern here is that you are proposing to name multiple things
"random". If this property should be called "random"--which I'm fine
with--then the static method "random(in:)" should be named something else,
and the static property "random" should be dropped altogether (as I
advocate for reasons we just discussed) or renamed as well. It is simply
too confusing that there are so many different "random" methods or
properties. Meanwhile, isn't your default RNG also going to be called
something like "DefaultRandom"?

In regards to the sample() function on collections, I have added this as I
> do believe this is something users need. The name I gave it was pick() as
> this reads, “From array, pick 2”.
>

The name "sample" has been used to good effect in other languages, has a
well understood meaning in statistics, and is consistent with Swift
language guidelines. The operation here is a sampling, and per Swift
guidelines the name must be a noun: therefore, 'sample' is fitting. "Pick"
does not intrinsically suggest randomness, whereas sample does, and your
proposed reading uses it as a verb, whereas Swift guidelines tell us it
must be a noun. I would advocate strongly for using well-established
terminology and sticking with "sample."


On Nov 17, 2017, 8:32 PM -0600, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org>, wrote:
>
> On Fri, Nov 17, 2017 at 7:11 PM, Brent Royal-Gordon <
> br...@architechies.com> wrote:
>
>> On Nov 17, 2017, at 3:09 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> But actually, Int.random followed by % is the much bigger issue and a
>> very good cautionary tale for why T.random is not a good idea. Swift should
>> help users do the correct thing, and getting a random value across the full
>> domain and computing an integer modulus is never the correct thing to do
>> because of modulo bias, yet it's a very common error to make. We are much
>> better off eliminating this API and encouraging use of the correct API,
>> thereby reducing the likelihood of users making this category of error.
>>
>>
>> Amen.
>>
>> If (and I agree with this) the range-based notation is less intuitive
>> (0..<10.random is certainly less discoverable than Int.random), then we
>> ought to offer an API in the form of `Int.random(in:)` but not
>> `Int.random`. This does not preclude a `Collection.random` API as Alejandro
>> proposes, of course, and that has independent value as Gwendal says.
>>
>>
>> If we're not happy with the range syntax, maybe we should put
>> `random(in:)`-style methods on the RNG protocol as extension methods
>> instead. Then there's a nice, uniform style:
>>
>> let diceRoll = rng.random(in: 1...6)
>> let card = rng.random(in: deck)
>> let isHeads = rng.random(in: [true, false])
>> let probability = rng.random(in: 0.0...1.0) // Special FloatingPoint
>> overload
>>
>> The only issue is that this makes the default RNG's name really
>> important. Something like:
>>
>> DefaultRandom.shared.random(in: 1...6)
>>
>> Will be a bit of a pain for users.
>>
>
> I did in fact implement this style of RNG in NumericAnnex, but I'm not
> satisfied with the design myself. Not only is it a bit of an ergonomic
> thorn, there's also another drawback that actually has weighty implications:
>
> Users aren't conditioned to reuse RNG instances. Perhaps, it is because it
> can "feel" wrong that multiple random instances should come from the *same*
> RNG. Instead, it "feels" more right to initialize a new RNG for every
> random number. After all, if one RNG is random, two must be randomer! This
> error is seen with some frequency in other languages that adopt this
> design, and they sometimes resort to educating users through documentation
> that isn't consistently heeded.
>
> Of course, you and I both know that this is not ideal for performance.
> Moreover, for a number of PRNG algorithms, the first few hundred or
> thousand iterations can be more predictable than later iterations. (Some
> algorithms discard the first n iterations, but whether that's adequate
> depends on the quality of the seed, IIUC.) Both of these issues don't apply
> specifically to a default RNG type that cannot be initialized and always
> uses entropy from the global pool, but that's not enough to vindicate the
> design, IMO. By 

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

[Xiaodi Wu via swift-evolution]

On Wed, Nov 22, 2017 at 22:55 Alejandro Alonso 
wrote:

> I pushed some updates to the proposal with a reflected API, but I do not
> agree that we should rid the API of T.random just because some users will
> misuse it. I think the correct solution here is to include T.random(in:)
> (which does not return an optional making it not a second typing of (min
> ... max).random). Like Jonathon said, autocomplete will display both of
> these and users will be able to select random(in:). I also disagree that
> T.random is _always_ followed by modulo because if we look at arc4random()
> it’s range is the whole domain of UInt32. Users don’t put a modulo here
> because they know the correct way to do it is through arc4random_uniform(),
> either through online tutorials, or by reading documentation. If we did get
> rid of T.random, users who want a random byte for instance would have to
> write UInt8.random(in: 0 … 255) every time. Developers will make wrappers
> over this. I believe the correct solution is to keep T.random for those who
> won’t misuse it and T.random(in:) for those who need to a random value
> within a range.
>

This is an exceedingly rare use case. Do you think it will be common that a
developer will want a single random byte? There will be much better ways to
request multiple bytes (through Data, for instance). And if a user wants
something like a value between 0...255 specifically, such as in the case of
elements of an RGB tuple, then (0...255).random is clearly a superior
spelling as compared to UInt8.random.

Quite simply, having seen how it is used in other languages, T.random is
vastly more likely to be misused than profitably used, by which I mean used
in a situation where an alternative spelling is clearly not good enough. It
should not be the simplest API offered, as its correct use is anything but
simple.


On Nov 17, 2017, 5:09 PM -0600, Xiaodi Wu , wrote:
>
> On Fri, Nov 17, 2017 at 10:10 AM, Gwendal Roué via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>> >
>> > If we go back to your example, you never call FixedWidthInteger.random
>> either, you call range.random. Does this mean integer types shouldn’t have
>> .random? No, because it means get a random number from it’s internal range
>> (alias to (min ... max).random). I think we can all agree that
>> Integer.random is a nicer api than making a range of its bounds. The same
>> goes for Date.random and Color.random.
>> >
>> > - Alejandro
>>
>> Hello,
>>
>> I'm not random expert, but it has never happened in my developer life
>> (backend & frontend app developer) that I have used a pure random value
>> from the full domain of the random type. In this life:
>>
>> - Int.random is _always_ followed by % modulo. Unless the better
>> arc4random_uniform(max) is used.
>> - Color.random is _never_ used, because random colors look bad.
>> - Date.random is _never_ used, because time is a physical unit, and
>> random points in time do not match any physical use case.
>>
>> This does not mean that random values from the full domain are useless.
>> Of course not: math apps, fuzzers, etc. need them.
>>
>> Yet a range-based API would be much welcomed by regular app developers.
>> And also Array.randomElement(), Array.shuffled(), etc, because there are
>> plenty naive and bad algorithms for those simple tasks.
>>
>
> Certainly it's hard to defend Date.random (and yes, it might be useful for
> a fuzzer, but that's a very niche use case--and in that case the fuzzer
> should probably also generate invalid/non-existent dates, which surely
> Date.random should not do). But actually, Int.random followed by % is the
> much bigger issue and a very good cautionary tale for why T.random is not a
> good idea. Swift should help users do the correct thing, and getting a
> random value across the full domain and computing an integer modulus is
> never the correct thing to do because of modulo bias, yet it's a very
> common error to make. We are much better off eliminating this API and
> encouraging use of the correct API, thereby reducing the likelihood of
> users making this category of error.
>
> If (and I agree with this) the range-based notation is less intuitive
> (0..<10.random is certainly less discoverable than Int.random), then we
> ought to offer an API in the form of `Int.random(in:)` but not
> `Int.random`. This does not preclude a `Collection.random` API as Alejandro
> proposes, of course, and that has independent value as Gwendal says.
>
>
>
___
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]

Like I’ve said, python has different syntax grammar. We have to read each call 
site and form a sentence from it. `random.choice([1, 2, 3])` to me this reads, 
“Get a random choice from array”. This makes sense. Slapping the word choice as 
an instance property like `[1, 2, 3].choice` reads, “From array, get choice”. 
What is choice? This doesn’t make sense at all to me. To me, the only good 
solution is `[1, 2, 3].random` which reads, “From array, get random”. I 
actually think most users will be able to understand this at first glance 
rather than choice (or any or some). In regards to the sample() function on 
collections, I have added this as I do believe this is something users need. 
The name I gave it was pick() as this reads, “From array, pick 2”.

- Alejandro

On Nov 17, 2017, 8:32 PM -0600, Xiaodi Wu via swift-evolution 
, wrote:
On Fri, Nov 17, 2017 at 7:11 PM, Brent Royal-Gordon 
> wrote:
On Nov 17, 2017, at 3:09 PM, Xiaodi Wu via swift-evolution 
> wrote:

But actually, Int.random followed by % is the much bigger issue and a very good 
cautionary tale for why T.random is not a good idea. Swift should help users do 
the correct thing, and getting a random value across the full domain and 
computing an integer modulus is never the correct thing to do because of modulo 
bias, yet it's a very common error to make. We are much better off eliminating 
this API and encouraging use of the correct API, thereby reducing the 
likelihood of users making this category of error.

Amen.

If (and I agree with this) the range-based notation is less intuitive 
(0..<10.random is certainly less discoverable than Int.random), then we ought 
to offer an API in the form of `Int.random(in:)` but not `Int.random`. This 
does not preclude a `Collection.random` API as Alejandro proposes, of course, 
and that has independent value as Gwendal says.

If we're not happy with the range syntax, maybe we should put 
`random(in:)`-style methods on the RNG protocol as extension methods instead. 
Then there's a nice, uniform style:

let diceRoll = rng.random(in: 1...6)
let card = rng.random(in: deck)
let isHeads = rng.random(in: [true, false])
let probability = rng.random(in: 0.0...1.0) // Special FloatingPoint overload

The only issue is that this makes the default RNG's name really important. 
Something like:

DefaultRandom.shared.random(in: 1...6)

Will be a bit of a pain for users.

I did in fact implement this style of RNG in NumericAnnex, but I'm not 
satisfied with the design myself. Not only is it a bit of an ergonomic thorn, 
there's also another drawback that actually has weighty implications:

Users aren't conditioned to reuse RNG instances. Perhaps, it is because it can 
"feel" wrong that multiple random instances should come from the *same* RNG. 
Instead, it "feels" more right to initialize a new RNG for every random number. 
After all, if one RNG is random, two must be randomer! This error is seen with 
some frequency in other languages that adopt this design, and they sometimes 
resort to educating users through documentation that isn't consistently heeded.

Of course, you and I both know that this is not ideal for performance. 
Moreover, for a number of PRNG algorithms, the first few hundred or thousand 
iterations can be more predictable than later iterations. (Some algorithms 
discard the first n iterations, but whether that's adequate depends on the 
quality of the seed, IIUC.) Both of these issues don't apply specifically to a 
default RNG type that cannot be initialized and always uses entropy from the 
global pool, but that's not enough to vindicate the design, IMO. By emphasizing 
*which* RNG instance is being used for random number generation, the design 
encourages non-reuse of non-default RNGs, which is precisely where this common 
error matters for performance (and maybe security).

Maybe we call the default RNG instance `random`, and then give the 
`random(in:)` methods another name, like `choose(in:)`?

let diceRoll = random.choose(in: 1...6)
let card = random.choose(in: deck)
let isHeads = random.choose(in: [true, false])
let probability = random.choose(in: 0.0...1.0)
let diceRoll = rng.choose(in: 1...6)
let card = rng.choose(in: deck)
let isHeads = rng.choose(in: [true, false])
let probability = rng.choose(in: 0.0...1.0)

This would allow us to keep the default RNG's type private and expose it only 
as an existential—which means more code will treat RNGs as black boxes, and 
people will extend the RNG protocol instead of the default RNG struct—while 
also putting our default random number generator under the name `random`, which 
is probably where people will look for such a thing.

I've said this already in my feedback, but it can get lost in the long chain of 
replies, so I'll repeat myself here because it's relevant to the discussion. I 
think one of the 

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

[Alejandro Alonso via swift-evolution]

I pushed some updates to the proposal with a reflected API, but I do not agree 
that we should rid the API of T.random just because some users will misuse it. 
I think the correct solution here is to include T.random(in:) (which does not 
return an optional making it not a second typing of (min ... max).random). Like 
Jonathon said, autocomplete will display both of these and users will be able 
to select random(in:). I also disagree that T.random is _always_ followed by 
modulo because if we look at arc4random() it’s range is the whole domain of 
UInt32. Users don’t put a modulo here because they know the correct way to do 
it is through arc4random_uniform(), either through online tutorials, or by 
reading documentation. If we did get rid of T.random, users who want a random 
byte for instance would have to write UInt8.random(in: 0 … 255) every time. 
Developers will make wrappers over this. I believe the correct solution is to 
keep T.random for those who won’t misuse it and T.random(in:) for those who 
need to a random value within a range.

- Alejandro

On Nov 17, 2017, 5:09 PM -0600, Xiaodi Wu , wrote:
On Fri, Nov 17, 2017 at 10:10 AM, Gwendal Roué via swift-evolution 
> wrote:

> Le 17 nov. 2017 à 16:04, Alejandro Alonso via swift-evolution 
> > a écrit :
>
> If we go back to your example, you never call FixedWidthInteger.random 
> either, you call range.random. Does this mean integer types shouldn’t have 
> .random? No, because it means get a random number from it’s internal range 
> (alias to (min ... max).random). I think we can all agree that Integer.random 
> is a nicer api than making a range of its bounds. The same goes for 
> Date.random and Color.random.
>
> - Alejandro

Hello,

I'm not random expert, but it has never happened in my developer life (backend 
& frontend app developer) that I have used a pure random value from the full 
domain of the random type. In this life:

- Int.random is _always_ followed by % modulo. Unless the better 
arc4random_uniform(max) is used.
- Color.random is _never_ used, because random colors look bad.
- Date.random is _never_ used, because time is a physical unit, and random 
points in time do not match any physical use case.

This does not mean that random values from the full domain are useless. Of 
course not: math apps, fuzzers, etc. need them.

Yet a range-based API would be much welcomed by regular app developers. And 
also Array.randomElement(), Array.shuffled(), etc, because there are plenty 
naive and bad algorithms for those simple tasks.

Certainly it's hard to defend Date.random (and yes, it might be useful for a 
fuzzer, but that's a very niche use case--and in that case the fuzzer should 
probably also generate invalid/non-existent dates, which surely Date.random 
should not do). But actually, Int.random followed by % is the much bigger issue 
and a very good cautionary tale for why T.random is not a good idea. Swift 
should help users do the correct thing, and getting a random value across the 
full domain and computing an integer modulus is never the correct thing to do 
because of modulo bias, yet it's a very common error to make. We are much 
better off eliminating this API and encouraging use of the correct API, thereby 
reducing the likelihood of users making this category of error.

If (and I agree with this) the range-based notation is less intuitive 
(0..<10.random is certainly less discoverable than Int.random), then we ought 
to offer an API in the form of `Int.random(in:)` but not `Int.random`. This 
does not preclude a `Collection.random` API as Alejandro proposes, of course, 
and that has independent value as Gwendal says.

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

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

[Howard Lovatt via swift-evolution]

You don't necessarily need variadic generics to enable tuples to be nominal
types. Though you do need some changes to the generic type system. One
possibility is:

struct Tuple_0_Int_1_Int: Collection /*where T0: T, T1: T*/
{ // Mangle name. Need covariant generics to enable constraint of T0 and T1.
typealias Element = T
typealias Index = Int
typealias SubSequence = Slice
var _0_: T/*0*/ // Unique name.
var _1_: T/*1*/ // Unique name.
let startIndex: Int = 0
let endIndex: Int = 2
subscript(position: Int) -> T {
switch position {
case 0: return _0_
case 1: return _1_
default: fatalError("Index out of bounds (must be 0 or 1).")
}
}
func index(after i: Int) -> Int {
return i + 1
}
}

// Ideally:
//   1. Extension on Tuple_0_Int_1_Int (SE-143).
//   2. Collection extension rather than on every Tuple (SE-143 extension).
func == (lhs: Tuple_0_Int_1_Int, rhs: Tuple_0_Int_1_Int) -> Bool
where T: Equatable {
let size = lhs.count
guard size == rhs.count else {
return false
}
for i in 0 ..< size {
guard lhs[i] == rhs[i] else {
return false
}
}
return true
}


The above is valid Swift 4, but I really want to be able to say:

   1. `struct Tuple_0_Int_1_Int: Collection where T0: T, T1: T`,
   i.e. covariant generics.
   2. Ideally SE143+ also, so that I can extend Collection to implement
   Equatable, Hashable, etc.

Note:

   1. Tuples extend Collection, not MutableCollection.
   2. T is the base type of T0 and T1.
   3. A Collection of T is sufficient to write interesting generic
   algorithms; equals, etc.


  -- Howard.

On 23 November 2017 at 11:50, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Nov 21, 2017, at 22:54, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
>
>
>
> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
>
> On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
>
> Or alternatively, one could decide to make the generics system *only and
> forever* work on nominal types, and make the syntactic sugar just be sugar
> for named types like Swift.Tuple, Function, and Optional.  Either design
> could work.
>
>
> We don’t have a way to make it work for function types, though, because of
> parameter-passing conventions. Well, assuming we don’t invent something
> that allows:
>
> Function
>
> to exist in the type system. Tuple labels have a similar problem.
>
>
> I’m totally aware of that and mentioned it upthread.
>
>
> Eh, sorry I missed it.
>
>  There are various encoding tricks that could make this work depending on
> how you want to stretch the current generics system…
>
>
> I think it’s straightforward and less ugly to make structural types allow
> extensions and protocol conformances.
>
>
> Can somebody explain to me what is less ugly about that? I would have
> naturally thought that the language would be simpler as a whole if there
> only existed nominal types and all structural types were just sugar over
> them.
>
>
> See Thorsten’s response with, e.g.,
>
>   Function
>
> which handles “inout” by adding wrappers around the parameter types (which
> one would have to cope with in any user of Function), but still doesn’t
> handle argument labels. To handle argument labels, we would need something
> like strings as generic arguments.
>
>
> Oh, good! A use case for “literals as generic parameters” *other* than
> Vectors and Fixed-Size Arrays!
>
> - Dave Sweeris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> On Nov 21, 2017, at 22:54, Douglas Gregor via swift-evolution 
>  wrote:
> 
>> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
>> 
>> 
>> 
>> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>>> 
>>> 
 On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
 
 On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
>> Or alternatively, one could decide to make the generics system *only and 
>> forever* work on nominal types, and make the syntactic sugar just be 
>> sugar for named types like Swift.Tuple, Function, and Optional.  Either 
>> design could work.
> 
> We don’t have a way to make it work for function types, though, because 
> of parameter-passing conventions. Well, assuming we don’t invent 
> something that allows:
> 
>   Function
> 
> to exist in the type system. Tuple labels have a similar problem.
 
 I’m totally aware of that and mentioned it upthread. 
>>> 
>>> Eh, sorry I missed it.
>>> 
  There are various encoding tricks that could make this work depending on 
 how you want to stretch the current generics system…
>>> 
>>> I think it’s straightforward and less ugly to make structural types allow 
>>> extensions and protocol conformances.
>> 
>> Can somebody explain to me what is less ugly about that? I would have 
>> naturally thought that the language would be simpler as a whole if there 
>> only existed nominal types and all structural types were just sugar over 
>> them.
> 
> See Thorsten’s response with, e.g.,
> 
> Function
> 
> which handles “inout” by adding wrappers around the parameter types (which 
> one would have to cope with in any user of Function), but still doesn’t 
> handle argument labels. To handle argument labels, we would need something 
> like strings as generic arguments.

Oh, good! A use case for “literals as generic parameters” other than Vectors 
and Fixed-Size Arrays!

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

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

[Mike Kluev via swift-evolution]

on Date: Tue, 21 Nov 2017 22:54:21 -0800 Douglas Gregor 
wrote:

> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
> >
> > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org > wrote:
> >
> >>
> >> I think it’s straightforward and less ugly to make structural types
> allow extensions and protocol conformances.
> >
> > Can somebody explain to me what is less ugly about that? I would have
> naturally thought that the language would be simpler as a whole if there
> only existed nominal types and all structural types were just sugar over
> them.
>
> See Thorsten’s response with, e.g.,
>
>   Function
>
> which handles “inout” by adding wrappers around the parameter types (which
> one would have to cope with in any user of Function), but still doesn’t
> handle argument labels. To handle argument labels, we would need something
> like strings as generic arguments. We’d also need to handle calling
> conventions and anything else we invent for function types.
>
>
can you outline how extensions and protocol conformances might look
for structural types? to compare the ugliness of both approaches.

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

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

[Howard Lovatt via swift-evolution]

I would defend turning tuples into structs (change from structural type to
nominal type). This is a much better story for programmers, compare the two
stories:

   1. Tuples are just syntax sugar for simple structs.
   2. Tuples are sort of like structs but there is a list of things tuples
   can do that structs can't and a list of things structs can do and tuples
   can't.

I think unification can be achieved with some name mangling (Chris Lattner
noted this previously - I am just spelling out one scheme), e.g.:

// var a = (zero: 0, one: 1)
public struct Tuple_zero_Int_one_Int { // Mangle name.
public var zero: Int
public var one: Int
}
var a = Tuple_zero_Int_one_Int(zero: 0, one: 1)
// a.0 = -1
a.zero = -1

// var b = (0, 1)
public struct Tuple_0_Int_1_Int { // Mangle name.
public var _0_: Int // Unique name.
public var _1_: Int // Unique name.
}
var b = Tuple_0_Int_1_Int(_0_: 0, _1_: 1)
// a = b
a = Tuple_zero_Int_one_Int(zero: b._0_, one: b._1_)


Implicit in the above transformation is:

   1. struct and tuple have the same memory layout.
   2. `.0` access the 1st stored property of a struct, `.1` the 2nd, etc.


  -- Howard.

On 22 November 2017 at 18:02, David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On 22 Nov 2017, at 07:54, Douglas Gregor  wrote:
>
>
>
> On Nov 21, 2017, at 10:48 PM, David Hart  wrote:
>
>
>
> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Nov 21, 2017, at 10:37 PM, Chris Lattner  wrote:
>
> On Nov 21, 2017, at 9:25 PM, Douglas Gregor  wrote:
>
> Or alternatively, one could decide to make the generics system *only and
> forever* work on nominal types, and make the syntactic sugar just be sugar
> for named types like Swift.Tuple, Function, and Optional.  Either design
> could work.
>
>
> We don’t have a way to make it work for function types, though, because of
> parameter-passing conventions. Well, assuming we don’t invent something
> that allows:
>
> Function
>
> to exist in the type system. Tuple labels have a similar problem.
>
>
> I’m totally aware of that and mentioned it upthread.
>
>
> Eh, sorry I missed it.
>
>  There are various encoding tricks that could make this work depending on
> how you want to stretch the current generics system…
>
>
> I think it’s straightforward and less ugly to make structural types allow
> extensions and protocol conformances.
>
>
> Can somebody explain to me what is less ugly about that? I would have
> naturally thought that the language would be simpler as a whole if there
> only existed nominal types and all structural types were just sugar over
> them.
>
>
> See Thorsten’s response with, e.g.,
>
>   Function
>
> which handles “inout” by adding wrappers around the parameter types (which
> one would have to cope with in any user of Function), but still doesn’t
> handle argument labels. To handle argument labels, we would need something
> like strings as generic arguments. We’d also need to handle calling
> conventions and anything else we invent for function types.
>
>
> Oh ok, I get. The ugliness comes from trying to shoehorn structural types
> into nominal types.
>
> - Doug
>
>
>
>
> ___
> 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] Make Optional, Array, and Dictionary conditionally Equatable

[Tony Allevato via swift-evolution]

Agree with the sentiment above. Equatable conformance for collections is
not just an obvious consequence of SE-0143 but one of the motivators—after
all, Array is mentioned right in the intro. Let it be done without a full
review cycle :)


On Wed, Nov 22, 2017 at 12:04 PM Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> +1 Agree with Chris with Doug’s suggestion to amend SE-0143 to document it.
>
>
> On Nov 22, 2017, at 10:08 AM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
> On Nov 22, 2017, at 9:48 AM, Chris Lattner  wrote:
>
> IMO this is obvious and you should put it in.
>
> The process serves a purpose: to ensure the evolution of the language is
> going in the right place, both directionally in an details.  It is obvious
> that we’re going to take this, and the details are clear, therefore doing
> an evolution cycle for this would just waste everyone’s time.
>
>
> I’ve been leaning this way as well. We can treat this small addition as an
> amendment to SE-0143 so the change is documented appropriately.
>
>
> That said, when you get to less obvious introductions and start doing more
> major consolidation and simplification of the stdlib, those changes may be
> worthy of discussion to ensure the details are right.
>
>
> Right. All of the consolidation of the various Slice and lazy types is big
> enough to warrant a proposal, for example.
>
>   - Doug
>
>
> -Chris
>
> On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi all,
>
> We’re having a bit of a debate  
> over
> the question of whether SE-0143 “Conditional Conformances”
> 
>  actually
> proposes any standard library changes at all, or whether they should all be
> brought up separately. So, I’ll pitch the pieces that I’d love to put into
> 4.1 to see if they’re as obvious as I think they should be :)
>
> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and
> Dictionary conform to Equatable when their type parameters are Equatable
> (and Set always conform to Equatable). Specifically, add to the standard
> library:
>
> extension Optional: Equatable where Wrapped: Equatable { /*== already
> exists */ }
> extension Array: Equatable where Element: Equatable { /*== already exists
> */ }
> extension ArraySlice: Equatable where Element: Equatable { /*== already
> exists */ }
> extension ContiguousArray: Equatable where Element: Equatable { /*==
> already exists */ }
> extension Dictionary: Equatable where Value: Equatable { /*== already
> exists */ }
> extension Set: Equatable { /*== already exists */ }
>
> Motivation: we need these for ==/!= to properly compose. It’s a
> highly-requested feature and an obvious “first use” of conditional
> conformances for the standard library that is unlikely to break any code.
>
> Implementation: https://github.com/apple/swift/pull/13046
>
> Thoughts?
>
>
> - Doug
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Hooman Mehr via swift-evolution]

+1 Agree with Chris with Doug’s suggestion to amend SE-0143 to document it.

> On Nov 22, 2017, at 10:08 AM, Douglas Gregor via swift-evolution 
>  wrote:
> On Nov 22, 2017, at 9:48 AM, Chris Lattner  > wrote:
> 
>> IMO this is obvious and you should put it in.
>> 
>> The process serves a purpose: to ensure the evolution of the language is 
>> going in the right place, both directionally in an details.  It is obvious 
>> that we’re going to take this, and the details are clear, therefore doing an 
>> evolution cycle for this would just waste everyone’s time.
> 
> I’ve been leaning this way as well. We can treat this small addition as an 
> amendment to SE-0143 so the change is documented appropriately. 
> 
>> 
>> That said, when you get to less obvious introductions and start doing more 
>> major consolidation and simplification of the stdlib, those changes may be 
>> worthy of discussion to ensure the details are right.
> 
> Right. All of the consolidation of the various Slice and lazy types is big 
> enough to warrant a proposal, for example. 
> 
>   - Doug
> 
>> 
>> -Chris
>> 
>>> On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> Hi all,
>>> 
>>> We’re having a bit of a debate  
>>> over the question of whether SE-0143 “Conditional Conformances” 
>>> 
>>>  actually proposes any standard library changes at all, or whether they 
>>> should all be brought up separately. So, I’ll pitch the pieces that I’d 
>>> love to put into 4.1 to see if they’re as obvious as I think they should be 
>>> :)
>>> 
>>> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
>>> conform to Equatable when their type parameters are Equatable (and Set 
>>> always conform to Equatable). Specifically, add to the standard library:
>>> 
>>> extension Optional: Equatable where Wrapped: Equatable { /*== already 
>>> exists */ }
>>> extension Array: Equatable where Element: Equatable { /*== already 
>>> exists */ }
>>> extension ArraySlice: Equatable where Element: Equatable { /*== already 
>>> exists */ }
>>> extension ContiguousArray: Equatable where Element: Equatable { /*== 
>>> already exists */ }
>>> extension Dictionary: Equatable where Value: Equatable { /*== already 
>>> exists */ }
>>> extension Set: Equatable { /*== already exists */ }
>>> 
>>> Motivation: we need these for ==/!= to properly compose. It’s a 
>>> highly-requested feature and an obvious “first use” of conditional 
>>> conformances for the standard library that is unlikely to break any code.
>>> 
>>> Implementation: https://github.com/apple/swift/pull/13046 
>>> 
>>> 
>>> Thoughts?
>>> 
>>> 
>>> - Doug
>>> 
>>> ___
>>> 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] Python Interop with Swift 4+

[Brent Royal-Gordon via swift-evolution]

> On Nov 20, 2017, at 10:50 AM, Slava Pestov via swift-evolution 
> > wrote:
> 
> What if you write ‘let fn = obj.method’?

Since Ruby doesn't distinguish between properties and methods, I would write 
the `subscript(dynamicProperty:)` getter to be equivalent to a zero-argument 
method call. This is a pragmatic tradeoff—property access is *way* more common 
than uncalled method access.

I assume that Swift would send `rubyObject.someMethod(_:_:)` through a 
method-related call, not a property-related one. Having a way to unambiguously 
specify a zero-argument method would allow the uncalled syntax to be used with 
Ruby methods which would otherwise be interpreted as properties.

(The setter on properties would handle the problem of Ruby's `=` methods. As 
for `?` and `!`, unless we extend the `identifier` syntax to allow 
non-identifier characters, I'd actually be tempted to bridge them with `is` and 
`unsafe` prefixes respectively. That might be a little too cute, though.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Thorsten Seitz via swift-evolution]

+1

-Thorsten


> Am 22.11.2017 um 18:48 schrieb Chris Lattner via swift-evolution 
> :
> 
> IMO this is obvious and you should put it in.
> 
> The process serves a purpose: to ensure the evolution of the language is 
> going in the right place, both directionally in an details.  It is obvious 
> that we’re going to take this, and the details are clear, therefore doing an 
> evolution cycle for this would just waste everyone’s time.
> 
> That said, when you get to less obvious introductions and start doing more 
> major consolidation and simplification of the stdlib, those changes may be 
> worthy of discussion to ensure the details are right.
> 
> -Chris
> 
>> On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> We’re having a bit of a debate  
>> over the question of whether SE-0143 “Conditional Conformances” 
>> 
>>  actually proposes any standard library changes at all, or whether they 
>> should all be brought up separately. So, I’ll pitch the pieces that I’d love 
>> to put into 4.1 to see if they’re as obvious as I think they should be :)
>> 
>> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
>> conform to Equatable when their type parameters are Equatable (and Set 
>> always conform to Equatable). Specifically, add to the standard library:
>> 
>>  extension Optional: Equatable where Wrapped: Equatable { /*== already 
>> exists */ }
>>  extension Array: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ArraySlice: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ContiguousArray: Equatable where Element: Equatable { /*== 
>> already exists */ }
>>  extension Dictionary: Equatable where Value: Equatable { /*== already 
>> exists */ }
>>  extension Set: Equatable { /*== already exists */ }
>> 
>> Motivation: we need these for ==/!= to properly compose. It’s a 
>> highly-requested feature and an obvious “first use” of conditional 
>> conformances for the standard library that is unlikely to break any code.
>> 
>> Implementation: https://github.com/apple/swift/pull/13046 
>> 
>> 
>> Thoughts?
>> 
>> 
>>  - Doug
>> 
>> ___
>> 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] Make Optional, Array, and Dictionary conditionally Equatable

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Nov 22, 2017, at 10:12 AM, Dave DeLong  wrote:
> 
> 
> 
>> On Nov 21, 2017, at 11:51 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> We’re having a bit of a debate over the question of whether SE-0143 
>> “Conditional Conformances” actually proposes any standard library changes at 
>> all, or whether they should all be brought up separately. So, I’ll pitch the 
>> pieces that I’d love to put into 4.1 to see if they’re as obvious as I think 
>> they should be :)
>> 
>> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
>> conform to Equatable when their type parameters are Equatable (and Set 
>> always conform to Equatable). Specifically, add to the standard library:
>> 
>>  extension Optional: Equatable where Wrapped: Equatable { /*== already 
>> exists */ }
>>  extension Array: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ArraySlice: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ContiguousArray: Equatable where Element: Equatable { /*== 
>> already exists */ }
>>  extension Dictionary: Equatable where Value: Equatable { /*== already 
>> exists */ }
>>  extension Set: Equatable { /*== already exists */ }
>> 
>> Motivation: we need these for ==/!= to properly compose. It’s a 
>> highly-requested feature and an obvious “first use” of conditional 
>> conformances for the standard library that is unlikely to break any code.
>> 
>> Implementation: https://github.com/apple/swift/pull/13046
>> 
>> Thoughts?
> 
> The reason these are on concrete types and not, say, Collection is because we 
> can’t conditionally conform protocols yet, right?

Right. SE-0143 has a discussion of this limitation. 

  - Doug

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

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Dave DeLong via swift-evolution]

> On Nov 21, 2017, at 11:51 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> We’re having a bit of a debate  
> over the question of whether SE-0143 “Conditional Conformances” 
> 
>  actually proposes any standard library changes at all, or whether they 
> should all be brought up separately. So, I’ll pitch the pieces that I’d love 
> to put into 4.1 to see if they’re as obvious as I think they should be :)
> 
> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
> conform to Equatable when their type parameters are Equatable (and Set always 
> conform to Equatable). Specifically, add to the standard library:
> 
>   extension Optional: Equatable where Wrapped: Equatable { /*== already 
> exists */ }
>   extension Array: Equatable where Element: Equatable { /*== already 
> exists */ }
>   extension ArraySlice: Equatable where Element: Equatable { /*== already 
> exists */ }
>   extension ContiguousArray: Equatable where Element: Equatable { /*== 
> already exists */ }
>   extension Dictionary: Equatable where Value: Equatable { /*== already 
> exists */ }
>   extension Set: Equatable { /*== already exists */ }
> 
> Motivation: we need these for ==/!= to properly compose. It’s a 
> highly-requested feature and an obvious “first use” of conditional 
> conformances for the standard library that is unlikely to break any code.
> 
> Implementation: https://github.com/apple/swift/pull/13046 
> 
> 
> Thoughts?

The reason these are on concrete types and not, say, Collection is because we 
can’t conditionally conform protocols yet, right?

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

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Nov 22, 2017, at 9:48 AM, Chris Lattner  wrote:
> 
> IMO this is obvious and you should put it in.
> 
> The process serves a purpose: to ensure the evolution of the language is 
> going in the right place, both directionally in an details.  It is obvious 
> that we’re going to take this, and the details are clear, therefore doing an 
> evolution cycle for this would just waste everyone’s time.

I’ve been leaning this way as well. We can treat this small addition as an 
amendment to SE-0143 so the change is documented appropriately. 

> 
> That said, when you get to less obvious introductions and start doing more 
> major consolidation and simplification of the stdlib, those changes may be 
> worthy of discussion to ensure the details are right.

Right. All of the consolidation of the various Slice and lazy types is big 
enough to warrant a proposal, for example. 

  - Doug

> 
> -Chris
> 
>> On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> We’re having a bit of a debate over the question of whether SE-0143 
>> “Conditional Conformances” actually proposes any standard library changes at 
>> all, or whether they should all be brought up separately. So, I’ll pitch the 
>> pieces that I’d love to put into 4.1 to see if they’re as obvious as I think 
>> they should be :)
>> 
>> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
>> conform to Equatable when their type parameters are Equatable (and Set 
>> always conform to Equatable). Specifically, add to the standard library:
>> 
>>  extension Optional: Equatable where Wrapped: Equatable { /*== already 
>> exists */ }
>>  extension Array: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ArraySlice: Equatable where Element: Equatable { /*== already 
>> exists */ }
>>  extension ContiguousArray: Equatable where Element: Equatable { /*== 
>> already exists */ }
>>  extension Dictionary: Equatable where Value: Equatable { /*== already 
>> exists */ }
>>  extension Set: Equatable { /*== already exists */ }
>> 
>> Motivation: we need these for ==/!= to properly compose. It’s a 
>> highly-requested feature and an obvious “first use” of conditional 
>> conformances for the standard library that is unlikely to break any code.
>> 
>> Implementation: https://github.com/apple/swift/pull/13046
>> 
>> Thoughts?
>> 
>> 
>>  - Doug
>> 
>> ___
>> 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] Make Optional, Array, and Dictionary conditionally Equatable

[Matthew Johnson via swift-evolution]

Seems like a no-brainer to me.  If there has been any argument against making 
this change I am really curious to know what it is.  I’m super excited that 
this might make it into 4.1.  Woohoo!!!

> On Nov 22, 2017, at 12:51 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> We’re having a bit of a debate  
> over the question of whether SE-0143 “Conditional Conformances” 
> 
>  actually proposes any standard library changes at all, or whether they 
> should all be brought up separately. So, I’ll pitch the pieces that I’d love 
> to put into 4.1 to see if they’re as obvious as I think they should be :)
> 
> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
> conform to Equatable when their type parameters are Equatable (and Set always 
> conform to Equatable). Specifically, add to the standard library:
> 
>   extension Optional: Equatable where Wrapped: Equatable { /*== already 
> exists */ }
>   extension Array: Equatable where Element: Equatable { /*== already 
> exists */ }
>   extension ArraySlice: Equatable where Element: Equatable { /*== already 
> exists */ }
>   extension ContiguousArray: Equatable where Element: Equatable { /*== 
> already exists */ }
>   extension Dictionary: Equatable where Value: Equatable { /*== already 
> exists */ }
>   extension Set: Equatable { /*== already exists */ }
> 
> Motivation: we need these for ==/!= to properly compose. It’s a 
> highly-requested feature and an obvious “first use” of conditional 
> conformances for the standard library that is unlikely to break any code.
> 
> Implementation: https://github.com/apple/swift/pull/13046 
> 
> 
> Thoughts?
> 
> 
>   - Doug
> 
> ___
> 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] Make Optional, Array, and Dictionary conditionally Equatable

[Chris Lattner via swift-evolution]

IMO this is obvious and you should put it in.

The process serves a purpose: to ensure the evolution of the language is going 
in the right place, both directionally in an details.  It is obvious that we’re 
going to take this, and the details are clear, therefore doing an evolution 
cycle for this would just waste everyone’s time.

That said, when you get to less obvious introductions and start doing more 
major consolidation and simplification of the stdlib, those changes may be 
worthy of discussion to ensure the details are right.

-Chris

> On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> We’re having a bit of a debate  
> over the question of whether SE-0143 “Conditional Conformances” 
> 
>  actually proposes any standard library changes at all, or whether they 
> should all be brought up separately. So, I’ll pitch the pieces that I’d love 
> to put into 4.1 to see if they’re as obvious as I think they should be :)
> 
> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
> conform to Equatable when their type parameters are Equatable (and Set always 
> conform to Equatable). Specifically, add to the standard library:
> 
>   extension Optional: Equatable where Wrapped: Equatable { /*== already 
> exists */ }
>   extension Array: Equatable where Element: Equatable { /*== already 
> exists */ }
>   extension ArraySlice: Equatable where Element: Equatable { /*== already 
> exists */ }
>   extension ContiguousArray: Equatable where Element: Equatable { /*== 
> already exists */ }
>   extension Dictionary: Equatable where Value: Equatable { /*== already 
> exists */ }
>   extension Set: Equatable { /*== already exists */ }
> 
> Motivation: we need these for ==/!= to properly compose. It’s a 
> highly-requested feature and an obvious “first use” of conditional 
> conformances for the standard library that is unlikely to break any code.
> 
> Implementation: https://github.com/apple/swift/pull/13046 
> 
> 
> Thoughts?
> 
> 
>   - Doug
> 
> ___
> 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] Synthesizing Concurrency: A Pitch For High-Level Abstractions & Low-Level Intelligence

[Pierre Habouzit via swift-evolution]

Hi, I'm on vacation and can't quite answer in depth, but this proposal 
encourages all the wrong things in terms of performance. We know from 10 years 
of GCD that mixing async/sync, while possible, yields significant performance 
issues, and I'd rather not have something at the core of the language 
encouraging it.

Actors seem like a much better way of solving these problems IMO.

-Pierre

> On Nov 16, 2017, at 1:50 PM, Christopher Heath via swift-evolution 
>  wrote:
> 
> Good evening all,
> 
> I had a little idea and thought I’d pitch it. So here goes!
> 
> Synthesizing Concurrency aims to provide a foundation by which, regardless of 
> concurrency implementation (however current proposal uses GCD examples for 
> design), concurrency can be synthesized by the compiler and remove many lines 
> of boilerplate code. Offering benefits to Application, Server and OS 
> Developers alike; with easy and intelligent concurrency conformance. Also, 
> should the community decide to head in another direction with concurrency 
> this should be a relatively mappable idea to any Synchronization Primitive 
> with a little work.
> 
> Thanks for looking, and I hope you like and want to contribute to the 
> discussion of the Synthesizing Concurrency proposal. I’ve added a printout 
> below. Please give it a read or check out the gist: 
> https://gist.github.com/XNUPlay/a0d6f6c0afdb3286e324c480cb5c4290 
> 
> Chris
> 
> Printout :
> Synthesizing Concurrency
> Proposal: SE- 
> 
> Author: Christopher Heath: XNUPlay 
> Review Manager: TBD
> Status: Pending Discussion
> Implementation: Awaiting Implementation
> Decision Notes: TBD
> 
> Introduction
> Developers have to write large amounts of boilerplate code to support 
> concurrency in complex types. This proposal offers a way for the compiler to 
> automatically synthesize conformance to a high-level Concurrent protocol to 
> reduce concurrent boilerplate code, in a set of scenarios where generating 
> the correct implementation is known to be possible.
> Specifically:
> It aims to provide a high-level Swift protocol that offers opt-in concurrency 
> support for any conformable type
> It aims to provide a well-defined set of thread-safe, concurrent 
> implementations for types, their properties, and methods.
> It aims to provide a language/library compatible implementation with deadlock 
> prevention.
> 
> Motivation
> Building robust types in Swift can involve writing significant boilerplate 
> code to support concurrency. By eliminating the complexity for the users, we 
> make Concurrent types much more appealing to users and allow them to use 
> their own types in optimized concurrent and parallel environments that 
> require thread safety with no added effort on their part (beyond declaring 
> the conformance).
> Concurrency is typically not pervasive across many types, and for each one 
> users must implement the concurrent code such that it performs some form of 
> synchronization to prevent unexpected behavior.
> 
> Note: Due to it's current status in Swift and use in the Runtime 
> ,
>  examples are written in Grand Central Dispatch 
> 
> 
> // Concurrent Protocol - Dispatch Example
> protocol Concurrent {
> // Synthesized Property
> var internalQueue: DispatchQueue { get }
> }
> 
> What's worse is that if any functions or properties are added, removed, or 
> changed, they must each have their own concurrency code and since it must be 
> manually written, it's possible to get it wrong, either by omission or 
> typographical error (async vs. sync).
> Likewise, it becomes necessary when one wishes to modify an existing type 
> that implements concurrency to do so without introducing bottlenecks or 
> different forms of synchronization for some functions and not others, this 
> leads to illegible and inefficient code that may defeat the purpose of 
> implementing concurrency.
> Crafting high-performance, readable concurrency code can be difficult and 
> inconvenient to write.
> Swift already derives conformance to a number of protocols, automatically 
> synthesizing their inner-workings when possible. Since there is precedent for 
> synthesized conformances in Swift, we propose extending it to concurrency in 
> predictable circumstances.
> 
> Proposed solution
> In general, we propose that a type synthesize conformance to Concurrent as 
> long as the compiler has reasonable insight into the type. We describe the 
> specific conditions under which these conformances are synthesized below, 
> followed by the details of how the conformance requirements are implemented.
> 
> Requesting synthesis is opt-in
> Users must opt-in to automatic synthesis 

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

[Karl Wagner via swift-evolution]

> On 22. Nov 2017, at 07:51, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> We’re having a bit of a debate  
> over the question of whether SE-0143 “Conditional Conformances” 
> 
>  actually proposes any standard library changes at all, or whether they 
> should all be brought up separately. So, I’ll pitch the pieces that I’d love 
> to put into 4.1 to see if they’re as obvious as I think they should be :)
> 
> Proposal: make Optional, Array, ArraySlice, ContiguousArray, and Dictionary 
> conform to Equatable when their type parameters are Equatable (and Set always 
> conform to Equatable). Specifically, add to the standard library:
> 
>   extension Optional: Equatable where Wrapped: Equatable { /*== already 
> exists */ }
>   extension Array: Equatable where Element: Equatable { /*== already 
> exists */ }
>   extension ArraySlice: Equatable where Element: Equatable { /*== already 
> exists */ }
>   extension ContiguousArray: Equatable where Element: Equatable { /*== 
> already exists */ }
>   extension Dictionary: Equatable where Value: Equatable { /*== already 
> exists */ }
>   extension Set: Equatable { /*== already exists */ }
> 
> Motivation: we need these for ==/!= to properly compose. It’s a 
> highly-requested feature and an obvious “first use” of conditional 
> conformances for the standard library that is unlikely to break any code.
> 
> Implementation: https://github.com/apple/swift/pull/13046 
> 
> 
> Thoughts?
> 
> 
>   - Doug
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I think they’re supposed to be brought up separately. There are actually a few 
areas of the standard library that have become outdated as we accepted new 
language features without corresponding proposals about using them. For 
example, we have top-level SetIndex and DictionaryIndex typealiases and 
SetIterator and DictionaryIterator types; dinosaurs from the era before nested 
generics.

As for this proposal? +1. Obviously.

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

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

[Mike Kluev via swift-evolution]

On 21 November 2017 at 21:55, Mike Kluev  wrote:

>
> maybe this?
>
> {
> capture weak foo, loo, poo // "capture list", if present
> capture unowned bar, baz, booz   // shall be at the beginning
> capture weak delegate = self.delegate!  // before anything else
>
> foo()
> ...
> }
>
> compare to the current:
> {
> [
> weak foo, weak loo, weak poo
> unowned bar, unowned baz, unowned booz
> weak delegate = self.delegate!
> ] in
>
> foo()
> ...
> }
>
> a bit more explicit / expressive, looks like ordinary statements, and
> doesn't have that strange "in" at the end.
>
>
or even this:

{
weak capture foo, loo, poo
unowned capture bar, baz, booz
weak capture delegate = self.delegate!

// capture list if any has to be before anything else

weak var some = other
foo()
...
 }

here "capture" is a noun, playing the role of "var" / "let".

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

Re: [swift-evolution] [Pitch #2] Introduce user-defined dynamically "callable" types

[David Hart via swift-evolution]

> On 22 Nov 2017, at 09:10, Alex Hoppen via swift-evolution 
>  wrote:
> 
> Would we really need the dynamicCall(method:arguments:) method and 
> DynamicCallableKeywordedMethod protocol for Smalltalk-like languages? 
> 
> I think in these languages, we could achieve keyword-argument-sensitive 
> method dispatch purely based on DynamicMemberLookupProtocol and 
> DynamicCallableWithKeywordsToo as follows:
> 
> - The dynamic member lookup returns a proxy object that stores the method 
> name and keeps a reference to the object on which the method shall be called. 
> This proxy conforms to DynamicCallableWithKeywordsToo.
> - At method call when the keyword arguments get passed, the proxy object 
> looks the method to be called up (it now has both the method name and all 
> keyword arguments) and immediately calls it.

That’s true, but what about access to properties? The proxy object would have 
to lazily call property getters, which could result in unexpected behaviour.

> – Alex
> 
>> On 21. Nov 2017, at 07:07, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hi All,
>> 
>> I’ve significantly revised the ‘dynamic callable’ pitch, here’s a second 
>> edition:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
>> 
>> I’ve incorporated a bunch of feedback from the first round of discussion:
>> 
>> - I’ve significantly increased the motivation section, talking about the 
>> value of solving this problem, and explaining why IMO an “ObjC Importer” 
>> approach is a bad idea.
>> - I’ve made it possible for (e.g.) a Javascript client to implement support 
>> for this while statically rejecting keyword arguments, but allow (e.g.) a 
>> Python implementation to accept them.
>> - I’ve expanded the model to support the name lookup requirements of Ruby 
>> and other smalltalk’y languages that require a base name + argument labels 
>> be present to resolve calls.
>> - I’ve expanded the alternatives section to explain why statically 
>> resolvable callables are orthogonal to this proposal and already pretty well 
>> served by Swift today.
>> - I’ve expanded the alternatives section to talk about F# type providers, 
>> explaining why they don’t solve this problem and are an interesting 
>> follow-on refinement to consider after taking this proposal (or something 
>> like it).
>> 
>> That said, there is at least one specific obviously bad thing about this 
>> proposal: the name “DynamicCallableWithKeywordsToo” which I appreciate help 
>> on.
>> 
>> If you’re interested in this topic, I’d really appreciate it if you’d read 
>> the new draft of the proposal.  It is significantly different than the 
>> original draft.  I welcome suggestions for improvements to the proposal, and 
>> insight into anything that is unclear or insufficiently motivated.
>> 
>> Thanks!
>> 
>> -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 #2] Introduce user-defined dynamically "callable" types

[Alex Hoppen via swift-evolution]

Would we really need the dynamicCall(method:arguments:) method and 
DynamicCallableKeywordedMethod protocol for Smalltalk-like languages? 

I think in these languages, we could achieve keyword-argument-sensitive method 
dispatch purely based on DynamicMemberLookupProtocol and 
DynamicCallableWithKeywordsToo as follows:

- The dynamic member lookup returns a proxy object that stores the method name 
and keeps a reference to the object on which the method shall be called. This 
proxy conforms to DynamicCallableWithKeywordsToo.
- At method call when the keyword arguments get passed, the proxy object looks 
the method to be called up (it now has both the method name and all keyword 
arguments) and immediately calls it.

– Alex

> On 21. Nov 2017, at 07:07, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi All,
> 
> I’ve significantly revised the ‘dynamic callable’ pitch, here’s a second 
> edition:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> 
> I’ve incorporated a bunch of feedback from the first round of discussion:
> 
> - I’ve significantly increased the motivation section, talking about the 
> value of solving this problem, and explaining why IMO an “ObjC Importer” 
> approach is a bad idea.
> - I’ve made it possible for (e.g.) a Javascript client to implement support 
> for this while statically rejecting keyword arguments, but allow (e.g.) a 
> Python implementation to accept them.
> - I’ve expanded the model to support the name lookup requirements of Ruby and 
> other smalltalk’y languages that require a base name + argument labels be 
> present to resolve calls.
> - I’ve expanded the alternatives section to explain why statically resolvable 
> callables are orthogonal to this proposal and already pretty well served by 
> Swift today.
> - I’ve expanded the alternatives section to talk about F# type providers, 
> explaining why they don’t solve this problem and are an interesting follow-on 
> refinement to consider after taking this proposal (or something like it).
> 
> That said, there is at least one specific obviously bad thing about this 
> proposal: the name “DynamicCallableWithKeywordsToo” which I appreciate help 
> on.
> 
> If you’re interested in this topic, I’d really appreciate it if you’d read 
> the new draft of the proposal.  It is significantly different than the 
> original draft.  I welcome suggestions for improvements to the proposal, and 
> insight into anything that is unclear or insufficiently motivated.
> 
> Thanks!
> 
> -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