Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

[Karl Wagner via swift-evolution]

> On 28. Nov 2017, at 02:34, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now 
> and runs through December 3, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
>  
> 
> Reply text
> Other replies
>  What 
> goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?

+1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes

> Does this proposal fit well with the feel and direction of Swift?
Yes

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I thought about this for a long time. Initially I was horrified, but I’ve come 
to the realisation that it is unnecessary and really makes it much easier to 
use Collection generically. If we didn’t already have this associatedtype, I 
don’t think anybody would ever ask for it. It’s perfectly reasonable for the 
standard-library’s Collection abstraction to be limited to the size of Int.

As Ben said, you can create your own Collection-style abstraction if that 
doesn’t fit your needs - and in fact, I have just such a protocol, exactly for 
the use-case that he described: a Collection-like file abstraction which I want 
to work on a 32-bit machine. That’s a reasonable solution.

The benefit I’ve found from doing that isn’t so much in Collection conformance 
itself, but just getting inspiration from how it (and its sister types) are 
structured. These niche cases are going to trip up most generic algorithms 
anyway, meaning all the benefits you got by conforming to Collection over just 
Sequence are now potential crashes. For example, if you call “map” on a 
collection with more than Int.max elements, the result Array couldn’t hold the 
data.

I could potentially see room for something between Sequence and Collection, 
like “Space” or something. An object which can retrieve sub-items by an index 
and whose count may be greater than the number of items storable at any one 
time in the host machine. Collection could refine “Space”, binding 
IndexDistance to Int (and effectively removing it as a parameter). The benefit 
of doing this is that we don’t lose (even theoretical) capability in the 
standard library, and we have some kind of migration path.

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> 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

[Thorsten Seitz via swift-evolution]

Shouldn't it be

random.choose(from: 1...6)

etc.?

-Thorsten 

> Am 28.11.2017 um 00:20 schrieb Martin Waitz via swift-evolution 
> :
> 
> Hello,
> 
>> 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)
> 
> I like this design a lot. After all, `random` is not a property of some type 
> or instance, but we want to generate a new random element within some 
> range/based on some given set.
> Modeling that as methods of the RNG seems to be much more natural.
> 
> -- 
> Martin
> ___
> 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

[Joe Groff via swift-evolution]

> On Nov 28, 2017, at 8:33 PM, Tony Allevato  wrote:
> 
> On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution 
>  wrote:
> On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
> > On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
> >
> > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
> >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution 
> >>> > wrote:
> >>>
> >>>
>  On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>  > wrote:
> 
>  when SE-185 
>  
>   went through swift evolution, it was agreed that the next logical step 
>   
>  is synthesizing these conformances for tuple types, though it was left 
>  out of the original proposal to avoid mission creep. I think now is the 
>  time to start thinking about this. i’m also tacking on Comparable to the 
>  other two protocols because there is precedent in the language from 
>  SE-15 
>  
>   that tuple comparison is something that makes sense to write.
> 
>  EHC conformance is even more important for tuples than it is for structs 
>  because tuples effectively have no workaround whereas in structs, you 
>  could just manually implement the conformance.
> >>>
> >>> In my opinion, you’re approaching this from the wrong direction.  The 
> >>> fundamental problem here is that tuples can’t conform to a protocol.  If 
> >>> they could, synthesizing these conformances would be straight-forward.
> >> It would be a tractable intermediate problem to introduce built-in 
> >> conformances for tuples (and perhaps metatypes) to 
> >> Equatable/Hashable/Comparable without breaching the more general topic of 
> >> allowing these types to have general protocol conformances. I think that 
> >> would cover the highest-value use cases.
> >
> > So, shouldn't we do this first step ASAP and then design a good common 
> > solution to allow tuples/metatypes/funcs to confirm to custom protocols in 
> > some next version of Swift?
> > I really believe this is the good practical decision and will be supported 
> > by community if such proposal will be on the table.
> > Is there any drawback in such step?
> 
> The expected behavior of tuple Equatable/Hashable/Comparable seems obvious to 
> me (though I could well be missing something), and any behavior we hardcode 
> should be naturally replaceable by a generalized conformance mechanism, so 
> it's primarily a "small matter of implementation". There would be some 
> implementation cost to managing the special case in the compiler and runtime; 
> the tradeoff seems worth it to me in this case, but others might reasonably 
> disagree. Not speaking for the entire core team, I would personally support 
> considering a proposal and implementation for builtin tuple 
> Equatable/Hashable/Comparable conformance.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> i wouldn’t know how to implement this but i could write up this proposal in a 
> few days 
> 
> I've been looking the past couple days at how to generalize the protocol 
> conformance machinery to support structural types (even if we don't support 
> arbitrary conformance syntactically, at least being able to hardcode the ones 
> we want to synthesize initially). My free time isn't exactly plentiful, but 
> I'm hoping to make some decent progress, so I'm happy to help where I can on 
> this since it's a natural follow-up to my other Equatable/Hashable work!

If I were going to look into implementing this, my first-pass approach would be 
something like this. It's not necessarily the best or most optimal approach, 
but it might get you started:

- Introduce a new ProtocolConformance subclass for tuple conformances, that 
collects the required protocol conformances from all the elements
- Enhance the AST and type checker conformance lookup machinery, such as 
lookupConformance and conformsToProtocol, to work with tuples, by returning 
TupleProtocolConformances where applicable
- In IRGen, lower a reference to a TupleProtocolConformance into a runtime call 
that grabs the conformance for a tuple type to a given protocol with the given 
element conformances
- In the runtime, implement these runtime calls similar to how we generate 
structural type metadata, with a uniquing cache that instantiates a unique 
witness table for each 

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner via swift-evolution]

> On Nov 28, 2017, at 8:57 PM, Slava Pestov  wrote:
> 
> Hi Chris,
> 
>> On Nov 28, 2017, at 8:54 PM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> “post.author" always invokes the DynamicMemberLookupProtocol proposal.
>> “post.author()” would invoke the “DynamicCallableWithKeywordsToo” hook in 
>> the dynamic callable proposal:
>> https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 
>> 
> Elsewhere in Swift, it is generally the case that
> 
> foo.bar()
> 
> is equivalent to
> 
> let fn = foo.bar
> fn()

That’s not actually the generally the case once you include some keyword 
arguments in the call.  Recall that function types don’t have keyword argument 
labels any longer, so:

foo.bar(x: 42)

Is not equivalent to:

let fn = foo.bar
fn(x: 42)


> Would this equivalence still hold with your proposal(s)?

It completely depends on the direction of the DynamicCallable proposal:
https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 


In my original proposal, I had no hook for “DynamicCallableWithKeywordsToo”.  
Feedback from the list was that people care about smalltalk derived languages 
(Ruby, Squeak, and yes, ObjC/Swift) and so I added this as a generalization.

That said, I’m not attached to it at all.  I can see the advantages of 
supporting these forms, but I can also see the concern that you’re observing.

I think that proponents for “DynamicCallableWithKeywordsToo” would say that 
Smalltalky languages (including Swift per the example above) do not provide the 
ability to separate out the base name, and those a bridge to those language can 
justifiably eject this concern.  In contrast, since Python *does* allow the 
substitution that you’re suggesting, its bridge absolutely would provide that 
capability.

In the end, it comes down to the cost benefit tradeoff we’ll have to weigh: how 
much generality and power is needed and can be justified?

-Chris

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner via swift-evolution]

> On Nov 28, 2017, at 10:12 AM, Paul Cantrell  wrote:
> Chris wrote:
>> Paul wrote:
>>> An “always use parens” bridge to Ruby has bad ergonomics
>>> Zero-arg Ruby methods are a mixture of property-like things that would 
>>> certainly not use parens in Swift, and function-like things that certainly 
>>> would:
>>> 
>>> // Idiomatic Swift:
>>> post.author.name.reversed()
>>> 
>>> // Swift bridging to Ruby…
>>> 
>>> // …if no-args methods •must• use parens:
>>> post.author().name().reverse()
>>> 
>>> // …if no-args methods •can’t• use parens:
>>> post.author.name.reverse
>>> 
>>> If the goal is to make Swift mostly feel like Swift even when bridging to 
>>> Ruby, then the bridge needs to support both access forms.
>> 
>> Ok, that can certainly be implemented by the two proposals I have in flight. 
>>  No obvious problem there.
> 
> 
> Chris, can you elaborate? I think the proposal precludes this; I must be 
> missing something!

There are two proposals in flight: one that allows specifying runtime behavior 
for “a.b” syntax and one that allows specifying runtime behavior for “a(x)” and 
“a.b(x)” syntax (“DynamicCallableWithKeywordsToo”, which needs to be renamed 
obviously).

For your use case, you’d implement both of them.  If someone wrote

a.b().c

Then you’d look up and call a zero-argument method named “b” on the a object.  
However if someone wrote:

a.b.c

Then you’d do the same thing (in the implementation of the 
DynamicMemberLookupProtocol).  This approach allows the human writing code at 
your bridge to use whatever syntax “feels best” to them given the specific API 
in question that they are using.

You could even have “a.b” syntax fall back to finding Ruby ivars as well, 
though I don’t know if that is actually a good idea in practice for a Ruby 
bridge.

> As I read the proposal, the dynamic member subscript for post.author returns 
> either a property value or a DynamicCallable, depending on whether the thing 
> is a property or a method — but post.author and post.author() would both look 
> identical to that subscript implementation, and there’s no distinction on the 
> Ruby side, so the subscript can’t know which one to return.

“post.author" always invokes the DynamicMemberLookupProtocol proposal.
“post.author()” would invoke the “DynamicCallableWithKeywordsToo” hook in the 
dynamic callable proposal:
https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 


-Chris

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner via swift-evolution]

> On Nov 27, 2017, at 9:03 PM, Magnus Ahltorp  wrote:
> Also, if the bridge author wants to return optionals all the time, that is 
> possible, right?

Yes, absolutely.  An example of that is already in the proposal.

-Chris

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner via swift-evolution]

> On Nov 28, 2017, at 5:58 PM, Greg Parker via swift-evolution 
>  wrote:
> 
> 
>> On Nov 27, 2017, at 8:57 AM, Mathew Huusko V via swift-evolution 
>> > wrote:
>> 
>> You're saying that there is universally no inherent difference, and that all 
>> calls "determine if you have called it" correctly, but then picked one of 
>> only a handful of cases in current practice where that is actually true. Yes 
>> "+" (/other math operators) and array access are unsafe, but most other 
>> things in Swift are safe by default, and you have to opt into un-safety 
>> (e.g. forcing or checking an optional or throwing call) — this is a main 
>> tenant of the language.
> 
> FYI this is not the definition of "safe" that Swift uses. Deliberately 
> halting the process in response to an error counts as "safe". This is what 
> Swift's arithmetic overflow and out of bounds array access do. 
> 
> "Unsafe" is when incorrect code both does something wrong and also doesn't 
> halt the process immediately. For example, using something like 
> UnsafeMutablePointer to perform an unsafe memory access that is incorrect 
> might read or write random memory and might do so without crashing.

Right.

> Swift often prefer throws or optional returns instead of runtime checks that 
> halt the process, but as you noted it does not always do so. I don't know if 
> we have a good phrase analogous to "safe"/"unsafe" for the presence/absence 
> of a runtime check that can halt the process.

Note that this proposal is safe by both definitions, because (as is shown in 
the proposal) an implementation of the protocol can implement the dynamic 
member as returning optional.  This provides a 100% safe interface to the 
client that doesn’t not "halt the process".

-Chris


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

[swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

[Brad Hilton via swift-evolution]

+1. Feels more Swifty to keep things simple when additional complexity isn’t 
warrented.

> Hello Swift community,
> 
> 
> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now 
> and runs through December 3, 2017. The proposal is available here:
> 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> > 
> > Proposal link:
> > 
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
> > 
> > Reply text
> > > Other replies
> > 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> 
> More information about the Swift evolution process is available at
> 
> > https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> 
> -Doug
> 
> 
> Review Manager
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner via swift-evolution]

> On Nov 28, 2017, at 1:55 PM, Ben Rimmington  wrote:
> 
> I suggest using different subscripts for function/method calls and properties:
> 
> * `value(...)`  ==> `value[dynamicFunction: ""](...)`
> * `value.name(...)` ==> `value[dynamicFunction: "name"](...)`
> * `value.name`  ==> `value[dynamicProperty: "name"]`
> 
> Dynamic callable types have an unnamed method.
> Dynamic argument labels are always allowed (but can be ignored).
> For example, the labels of `Date.UTC` below are not passed to JavaScript.

Hi Ben,

This proposal has nothing to do with “callables”, just dynamics member lookup.  
The other proposal: 
https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d 
 (which I 
need to revise a bit) relates to dynamic callable stuff, and it does in fact 
have a “DynamicCallableWithKeywordsToo” form that provides what you are asking 
for IIUC.

There is no need to model calls as subscripts though, because syntactic calls 
in swift (intentionally) do not produce lvalues.

-Chris

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

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner via swift-evolution]

> On Nov 27, 2017, at 7:31 PM, Xiaodi Wu  wrote:
> 
> Better yet, since we previously started to require “@objc dynamic” instead of 
> “dynamic” with the notion that perhaps there would be some future non-ObjC 
> dynamism, we *could* have it spelt “dynamic member(_:)”.

I’m super open the changing the spelling of anything in the proposal.  That 
said, if you really mean to suggest that we introduce some new syntactic form, 
I’d be wary of that.  It increases the scope of the proposal and makes the 
cost/benefit tradeoff harder to justify.  One of the things that I think is 
compelling about this is that the cost of it is very low (it really does fit 
naturally into the existing architecture of the compiler), which means that the 
narrow benefit is justifiable (IMO).

> But this is all just spelling now; I think the overall design is compelling 
> in its elegance and power.

I’m glad to hear that, thanks!

-Chris

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

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner via swift-evolution]

> On Nov 27, 2017, at 6:21 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Nov 25, 2017, at 3:16 PM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>> Just to talk to myself a bit here, but I’ve come to realize that the right 
>> design really is to have a simple empty marker protocol like this:
> 
> If you're reaching this point. why have a marker protocol at all? Why not 
> treat `subscript(dynamicMember:)` specially on any type that has it, or have 
> an `@dynamicMember subscript(_:)` attribute, or introduce an entire new 
> `dynamicMember(_:)` declaration?

We’ve had a lot of discussions over the years about how to balance simplicity 
vs power, implicitness vs explicitness, intentionality vs accidental behavior, 
etc.  For example, in very early discussions about Swift generics, some folks 
where strong proponents of protocol conformance being fully implicit: 
satisfying all the requirements of a protocol meant that you conformed to it, 
even if you didn’t explicitly “inherit” from it.

This is obviously not the design we went with over the long term, and I’m glad 
we didn’t.  That said, if we did, then all of the “ExpressibleBy” protocols 
wouldn’t  need to exist: we’d probably just say that it was enough to implement 
the requirements to get the behavior and elide the protocol declaration 
entirely.

I think that DynamicMemberLookup requiring conformance is the same thing: it 
makes it explicit that the behavior is intentional, and it allows somewhat 
better error checking (if you conform to the protocol but don’t implement the 
(implicitly known) requirement, you DO get an error).  That said, this is just 
my opinion.  

Do you feel strongly enough about this that you’d like to make a strong 
argument for changing the behavior?

-Chris

___
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

[Tony Allevato via swift-evolution]

On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution <
swift-evolution@swift.org> wrote:

> On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> > On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
>> >
>> > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
>> >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org > wrote:
>> >>>
>> >>>
>>  On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org > wrote:
>> 
>>  when SE-185 <
>> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md>
>> went through swift evolution, it was agreed that the next logical step <
>> https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html> is
>> synthesizing these conformances for tuple types, though it was left out of
>> the original proposal to avoid mission creep. I think now is the time to
>> start thinking about this. i’m also tacking on Comparable to the other two
>> protocols because there is precedent in the language from SE-15 <
>> https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md>
>> that tuple comparison is something that makes sense to write.
>> 
>>  EHC conformance is even more important for tuples than it is for
>> structs because tuples effectively have no workaround whereas in structs,
>> you could just manually implement the conformance.
>> >>>
>> >>> In my opinion, you’re approaching this from the wrong direction.  The
>> fundamental problem here is that tuples can’t conform to a protocol.  If
>> they could, synthesizing these conformances would be straight-forward.
>> >> It would be a tractable intermediate problem to introduce built-in
>> conformances for tuples (and perhaps metatypes) to
>> Equatable/Hashable/Comparable without breaching the more general topic of
>> allowing these types to have general protocol conformances. I think that
>> would cover the highest-value use cases.
>> >
>> > So, shouldn't we do this first step ASAP and then design a good common
>> solution to allow tuples/metatypes/funcs to confirm to custom protocols in
>> some next version of Swift?
>> > I really believe this is the good practical decision and will be
>> supported by community if such proposal will be on the table.
>> > Is there any drawback in such step?
>>
>> The expected behavior of tuple Equatable/Hashable/Comparable seems
>> obvious to me (though I could well be missing something), and any behavior
>> we hardcode should be naturally replaceable by a generalized conformance
>> mechanism, so it's primarily a "small matter of implementation". There
>> would be some implementation cost to managing the special case in the
>> compiler and runtime; the tradeoff seems worth it to me in this case, but
>> others might reasonably disagree. Not speaking for the entire core team, I
>> would personally support considering a proposal and implementation for
>> builtin tuple Equatable/Hashable/Comparable conformance.
>>
>> -Joe
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> i wouldn’t know how to implement this but i could write up this proposal
> in a few days
>

I've been looking the past couple days at how to generalize the protocol
conformance machinery to support structural types (even if we don't support
arbitrary conformance syntactically, at least being able to hardcode the
ones we want to synthesize initially). My free time isn't exactly
plentiful, but I'm hoping to make some decent progress, so I'm happy to
help where I can on this since it's a natural follow-up to my other
Equatable/Hashable work!


>
> ___
> 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: Introduce User-defined "Dynamic Member Lookup" Types

[Greg Parker via swift-evolution]

> On Nov 27, 2017, at 8:57 AM, Mathew Huusko V via swift-evolution 
>  wrote:
> 
> You're saying that there is universally no inherent difference, and that all 
> calls "determine if you have called it" correctly, but then picked one of 
> only a handful of cases in current practice where that is actually true. Yes 
> "+" (/other math operators) and array access are unsafe, but most other 
> things in Swift are safe by default, and you have to opt into un-safety (e.g. 
> forcing or checking an optional or throwing call) — this is a main tenant of 
> the language.

FYI this is not the definition of "safe" that Swift uses. Deliberately halting 
the process in response to an error counts as "safe". This is what Swift's 
arithmetic overflow and out of bounds array access do. 

"Unsafe" is when incorrect code both does something wrong and also doesn't halt 
the process immediately. For example, using something like UnsafeMutablePointer 
to perform an unsafe memory access that is incorrect might read or write random 
memory and might do so without crashing.

Swift often prefer throws or optional returns instead of runtime checks that 
halt the process, but as you noted it does not always do so. I don't know if we 
have a good phrase analogous to "safe"/"unsafe" for the presence/absence of a 
runtime check that can halt the process.


-- 
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] Synthesizing Equatable, Hashable, and Comparable for tuple types

[Jonathan Hull via swift-evolution]

+1.  It seems like a practical first step.

> On Nov 28, 2017, at 10:59 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
> 
>> On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
>> 
>> On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
 On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution 
 > wrote:
 
 
> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
> > wrote:
> 
> when SE-185 
> 
>  went through swift evolution, it was agreed that the next logical step 
>  is 
> synthesizing these conformances for tuple types, though it was left out 
> of the original proposal to avoid mission creep. I think now is the time 
> to start thinking about this. i’m also tacking on Comparable to the other 
> two protocols because there is precedent in the language from SE-15 
> 
>  that tuple comparison is something that makes sense to write.
> 
> EHC conformance is even more important for tuples than it is for structs 
> because tuples effectively have no workaround whereas in structs, you 
> could just manually implement the conformance. 
 
 In my opinion, you’re approaching this from the wrong direction.  The 
 fundamental problem here is that tuples can’t conform to a protocol.  If 
 they could, synthesizing these conformances would be straight-forward.
>>> It would be a tractable intermediate problem to introduce built-in 
>>> conformances for tuples (and perhaps metatypes) to 
>>> Equatable/Hashable/Comparable without breaching the more general topic of 
>>> allowing these types to have general protocol conformances. I think that 
>>> would cover the highest-value use cases.
>> 
>> So, shouldn't we do this first step ASAP and then design a good common 
>> solution to allow tuples/metatypes/funcs to confirm to custom protocols in 
>> some next version of Swift?
>> I really believe this is the good practical decision and will be supported 
>> by community if such proposal will be on the table.
>> Is there any drawback in such step?
> 
> The expected behavior of tuple Equatable/Hashable/Comparable seems obvious to 
> me (though I could well be missing something), and any behavior we hardcode 
> should be naturally replaceable by a generalized conformance mechanism, so 
> it's primarily a "small matter of implementation". There would be some 
> implementation cost to managing the special case in the compiler and runtime; 
> the tradeoff seems worth it to me in this case, but others might reasonably 
> disagree. Not speaking for the entire core team, I would personally support 
> considering a proposal and implementation for builtin tuple 
> Equatable/Hashable/Comparable conformance.
> 
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Ben Rimmington via swift-evolution]

> On 28 Nov 2017, at 22:06, Jean-Daniel  wrote:
> 
> While I perfectly understand why subscript is the best way to represent 
> dynamic property, I don’t get how it help to abuse it to implement dynamic 
> methods. Methods are not l-value, so why do you want to use a subscript for 
> them ?

First, I tried overloading `subscript(dynamicMember:)` by return type.

subscript(dynamicMember name: String) -> (_ arguments: Any...) -> JSValue
subscript(dynamicMember name: String) -> JSValue

It allows for method calls without the DynamicCallable proposal.

context[dynamicMember: "Math"][dynamicMember: "pow"](2, 53)
//-> 9007199254740992

context[dynamicMember: "Math"][dynamicMember: "PI"] as JSValue
//-> 3.1415926535897931

context[dynamicMember: "Math"][dynamicMember: "PI"]
//ERROR: Ambiguous use of 'subscript(dynamicMember:)'

This evolved into the differently labelled subscripts,
to avoid having to disambiguate by return type.

But you're right, a function might be better than a subscript.

-- Ben

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

[swift-evolution] Update: Moving to Discourse

[Nicole Jacque via swift-evolution]

Hi All-

I just wanted to update you all on our migration to Discourse.  We are well on 
our way, with a prototype server and initial import of mailing list data 
completed! 

As part of the move to Discourse, we have the opportunity to do some 
re-organization to help foster communication and collaboration. A number of 
people stepped up to be part of a workgroup to help work through decisions 
about the structure and setup of the new forums.  In a week or two, we’ll be 
ready to come back and present our proposed forum setup. At that time we will 
also have a beta of the forum with (stale) imported mailing list data for 
people to take a look at.  

My hope is that we can tie up loose ends, schedule the final migration and 
cut-over to the forums about a week later, sometime during the week of Dec. 18. 
 As we get closer, I’ll communicate more concrete dates.

Cheers!
Nicole

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

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Matthew Johnson via swift-evolution]

> On Nov 28, 2017, at 4:11 PM, Slava Pestov  wrote:
> 
> 
> 
>> On Nov 28, 2017, at 1:35 PM, Matthew Johnson > > wrote:
>> 
 * the compiler doesn’t have to reason about an overload set which might 
 improve build times, etc
>>> 
>>> They’re effectively equivalent, because we still have to decide which 
>>> subset of the default arguments apply at a given call site by checking all 
>>> combinations of constraints.
>> 
>> Interesting.  Are there no advantages to the compiler that would be possible 
>> if an overload set was replaced with constrained default arguments?
>> 
> 
> Probably not. In general I’m wary of designing language features specifically 
> to speed up the type checker, since they make not have the intended effect or 
> even the opposite effect. We know the type checker implementation is not the 
> best possible implementation of a type checker — there is a lot we can 
> improve without changing the language.

That isn’t the motivation here.  I thought it might be an incidental benefit.  
If it isn’t the motivating use case still stands.  Of course it may or may not 
be sufficient to justify the feature.  :)

> 
> Slava

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

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Slava Pestov via swift-evolution]

> On Nov 28, 2017, at 1:35 PM, Matthew Johnson  wrote:
> 
>>> * the compiler doesn’t have to reason about an overload set which might 
>>> improve build times, etc
>> 
>> They’re effectively equivalent, because we still have to decide which subset 
>> of the default arguments apply at a given call site by checking all 
>> combinations of constraints.
> 
> Interesting.  Are there no advantages to the compiler that would be possible 
> if an overload set was replaced with constrained default arguments?
> 

Probably not. In general I’m wary of designing language features specifically 
to speed up the type checker, since they make not have the intended effect or 
even the opposite effect. We know the type checker implementation is not the 
best possible implementation of a type checker — there is a lot we can improve 
without changing the language.

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Jean-Daniel via swift-evolution]

> Le 28 nov. 2017 à 22:56, Ben Rimmington via swift-evolution 
>  a écrit :
> 
> I suggest using different subscripts for function/method calls and properties:
> 

While I perfectly understand why subscript is the best way to represent dynamic 
property, I don’t get how it help to abuse it to implement dynamic methods. 
Methods are not l-value, so why do you want to use a subscript for them ?

> * `value(...)`  ==> `value[dynamicFunction: ""](...)`
> * `value.name(...)` ==> `value[dynamicFunction: "name"](...)`
> * `value.name`  ==> `value[dynamicProperty: "name"]`
> …
> ___
> 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: Introduce User-defined "Dynamic Member Lookup" Types

[Ben Rimmington via swift-evolution]

I suggest using different subscripts for function/method calls and properties:

* `value(...)`  ==> `value[dynamicFunction: ""](...)`
* `value.name(...)` ==> `value[dynamicFunction: "name"](...)`
* `value.name`  ==> `value[dynamicProperty: "name"]`

Dynamic callable types have an unnamed method.
Dynamic argument labels are always allowed (but can be ignored).
For example, the labels of `Date.UTC` below are not passed to JavaScript.

//===--===//
//  JavaScriptCore.playground
//===--===//

import Foundation
import JavaScriptCore

typealias Arguments = DictionaryLiteral

extension JSContext {

subscript(dynamicFunction name: String) -> (_ arguments: Arguments) -> 
JSValue {
return globalObject[dynamicFunction: name]
}

subscript(dynamicProperty name: String) -> JSValue {
get {
return globalObject[dynamicProperty: name]
}
set {
globalObject[dynamicProperty: name] = newValue
}
}
}

extension JSValue {

subscript(dynamicFunction name: String) -> (_ arguments: Arguments) -> 
JSValue {
return { arguments in
let argumentValues = arguments.map({ $0.value })
if name.isEmpty {
return self.call(withArguments: argumentValues)
} else if name == "new" {
return self.construct(withArguments: argumentValues)
} else {
return self.invokeMethod(name, withArguments: argumentValues)
}
}
}

subscript(dynamicProperty name: String) -> JSValue {
get {
return forProperty(name)
}
set {
setValue(newValue, forProperty: name)
}
}
}

//===--===//
//  Examples
//===--===//

let context = JSContext()!

//: ```
//: context.isNaN(Double.nan)
//: ```
context[dynamicFunction: "isNaN"](["": Double.nan])

//: ```
//: context.Math.PI
//: ```
context[dynamicProperty: "Math"][dynamicProperty: "PI"]

//: ```
//: context.Math.PI.toFixed(5)
//: ```
context[dynamicProperty: "Math"][dynamicProperty: "PI"][dynamicFunction: 
"toFixed"](["": 5])

//: ```
//: context.Math.pow(2, 53)
//: ```
context[dynamicProperty: "Math"][dynamicFunction: "pow"](["": 2, "": 53])

//: ```
//: let time = context.Date.UTC(
//: year: , month: 11, day: 31,
//: hour: 23, minute: 59, second: 59, millisecond: 999)
//: ```
let time = context[dynamicProperty: "Date"][dynamicFunction: "UTC"]([
"year": , "month": 11, "day": 31,
"hour": 23, "minute": 59, "second": 59, "millisecond": 999])

//: ```
//: let date = context.Date.new(time)
//: ```
let date = context[dynamicProperty: "Date"][dynamicFunction: "new"](["": time])

//: ```
//: date.toISOString()
//: ```
date[dynamicFunction: "toISOString"]([:])


> On 27 Nov 2017, at 06:04, Chris Lattner wrote:
> 
> I’d like to formally propose the inclusion of user-defined dynamic member 
> lookup types.
> 
> Here is my latest draft of the proposal:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> https://github.com/apple/swift-evolution/pull/768
> 
> An implementation of this design is available here:
> https://github.com/apple/swift/pull/13076
> 
> The implementation is straight-forward and (IMO) non-invasive in the compiler.
> 
> -Chris

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

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Matthew Johnson via swift-evolution]

> On Nov 28, 2017, at 3:28 PM, Slava Pestov  wrote:
> 
> 
> 
>> On Nov 28, 2017, at 1:25 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Nov 28, 2017, at 3:18 PM, Slava Pestov >> > wrote:
>>> 
>>> 
>>> 
 On Nov 28, 2017, at 8:44 AM, Matthew Johnson > wrote:
 
 func makeResource(
 with configuration: Configuration = () where Configuration == Void, 
 actionHandler: @escaping (Action) -> Void = { _ in } where Action == 
 Never
 )
>>> 
>>> Similar question to the one I posed earlier — what happens if I’m using 
>>> makeResource() from a generic context? Is the conditional default argument 
>>> simply not available?
>> 
>> Right.  If the constraints are not met at the call site the default is not 
>> available.  I think you understood, but looking at the example above I 
>> omitted the resource type parameter.  It should read:
>> 
>> func makeResource(
>> with configuration: R.Configuration = () where R.Configuration == Void, 
>> actionHandler: @escaping (R.Action) -> Void = { _ in } where R.Action == 
>> Never
>> )
>> 
>>> 
>>> In this case, how is it different from defining some static overloads of 
>>> makeResource(), some of which have default arguments and some of which are 
>>> generic?
>> 
>> From the point of view of the call site it is not different.  The 
>> differences are that:
>> 
>> * the user is presented with a single API rather than several overloads
> 
> Is this less confusing than encountering a new ‘where’ clause on default 
> arguments, which is probably rare enough that many users will spend 
> months/years using Swift without seeing it?

I think so.  The where clause is used for constraints consistently in the 
language so the meaning of seeing one attached to a default argument should be 
intuitive for anyone familiar with the generics system.  In the motivating use 
case I have there would still be an overload set available but it would be much 
smaller with this feature and therefore the available signatures would be much 
more clear.

> 
>> * the compiler doesn’t have to reason about an overload set which might 
>> improve build times, etc
> 
> They’re effectively equivalent, because we still have to decide which subset 
> of the default arguments apply at a given call site by checking all 
> combinations of constraints.

Interesting.  Are there no advantages to the compiler that would be possible if 
an overload set was replaced with constrained default arguments?

> 
> Slava
> 
>> 
>>> 
>>> Slava
>> 
> 

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

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Matthew Johnson via swift-evolution]

> On Nov 28, 2017, at 3:18 PM, Slava Pestov  wrote:
> 
> 
> 
>> On Nov 28, 2017, at 8:44 AM, Matthew Johnson > > wrote:
>> 
>> func makeResource(
>> with configuration: Configuration = () where Configuration == Void, 
>> actionHandler: @escaping (Action) -> Void = { _ in } where Action == 
>> Never
>> )
> 
> Similar question to the one I posed earlier — what happens if I’m using 
> makeResource() from a generic context? Is the conditional default argument 
> simply not available?

Right.  If the constraints are not met at the call site the default is not 
available.  I think you understood, but looking at the example above I omitted 
the resource type parameter.  It should read:

func makeResource(
with configuration: R.Configuration = () where R.Configuration == Void, 
actionHandler: @escaping (R.Action) -> Void = { _ in } where R.Action == 
Never
)

> 
> In this case, how is it different from defining some static overloads of 
> makeResource(), some of which have default arguments and some of which are 
> generic?

>From the point of view of the call site it is not different.  The differences 
>are that:

* the user is presented with a single API rather than several overloads
* the library author isn’t required to maintain an overload set
* the compiler doesn’t have to reason about an overload set which might improve 
build times, etc

> 
> Slava

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

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Slava Pestov via swift-evolution]

> On Nov 28, 2017, at 8:44 AM, Matthew Johnson  wrote:
> 
> func makeResource(
> with configuration: Configuration = () where Configuration == Void, 
> actionHandler: @escaping (Action) -> Void = { _ in } where Action == Never
> )

Similar question to the one I posed earlier — what happens if I’m using 
makeResource() from a generic context? Is the conditional default argument 
simply not available?

In this case, how is it different from defining some static overloads of 
makeResource(), some of which have default arguments and some of which are 
generic?

Slava___
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

[Nevin Brackett-Rozinsky via swift-evolution]

On Tue, Nov 28, 2017 at 1:05 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
> To close the loop here, the core team has agreed to this as an amendment
> to SE-0143, and the changed has been merged here:
>
> https://github.com/apple/swift-evolution/pull/769
>
> and we’ve merged the change into the Swift standard library for Swift 4.1,
> here:
>
> https://github.com/apple/swift/pull/13046
>
> - Doug
>


Huzzah!
___
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

[Kelvin Ma via swift-evolution]

On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> > On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
> >
> > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
> >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org > wrote:
> >>>
> >>>
>  On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org > wrote:
> 
>  when SE-185  proposals/0185-synthesize-equatable-hashable.md> went through swift
> evolution, it was agreed that the next logical step <
> https://www.mail-archive.com/swift-evolution@swift.org/msg26162.html> is
> synthesizing these conformances for tuple types, though it was left out of
> the original proposal to avoid mission creep. I think now is the time to
> start thinking about this. i’m also tacking on Comparable to the other two
> protocols because there is precedent in the language from SE-15 <
> https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-
> comparison-operators.md> that tuple comparison is something that makes
> sense to write.
> 
>  EHC conformance is even more important for tuples than it is for
> structs because tuples effectively have no workaround whereas in structs,
> you could just manually implement the conformance.
> >>>
> >>> In my opinion, you’re approaching this from the wrong direction.  The
> fundamental problem here is that tuples can’t conform to a protocol.  If
> they could, synthesizing these conformances would be straight-forward.
> >> It would be a tractable intermediate problem to introduce built-in
> conformances for tuples (and perhaps metatypes) to
> Equatable/Hashable/Comparable without breaching the more general topic of
> allowing these types to have general protocol conformances. I think that
> would cover the highest-value use cases.
> >
> > So, shouldn't we do this first step ASAP and then design a good common
> solution to allow tuples/metatypes/funcs to confirm to custom protocols in
> some next version of Swift?
> > I really believe this is the good practical decision and will be
> supported by community if such proposal will be on the table.
> > Is there any drawback in such step?
>
> The expected behavior of tuple Equatable/Hashable/Comparable seems obvious
> to me (though I could well be missing something), and any behavior we
> hardcode should be naturally replaceable by a generalized conformance
> mechanism, so it's primarily a "small matter of implementation". There
> would be some implementation cost to managing the special case in the
> compiler and runtime; the tradeoff seems worth it to me in this case, but
> others might reasonably disagree. Not speaking for the entire core team, I
> would personally support considering a proposal and implementation for
> builtin tuple Equatable/Hashable/Comparable conformance.
>
> -Joe
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

i wouldn’t know how to implement this but i could write up this proposal in
a few days
___
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

[Kelvin Ma via swift-evolution]

On Tue, Nov 28, 2017 at 3:18 AM, Xiaodi Wu  wrote:

>
> On Tue, Nov 28, 2017 at 00:32 Kelvin Ma  wrote:
>
>> On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu  wrote:
>>
>>> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma  wrote:
>>>


 On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu  wrote:

> On Mon, Nov 27, 2017 at 15:46 Taylor Swift 
> wrote:
>
>> they use packed buffers of floats, which for type safety are better
>> rebound to a structured type. right now (Float, Float, Float) works 
>> because
>> the tuple is laid out contiguously and the GPU can’t tell the difference
>> but it’s not guaranteed. also you’re ignoring all the CPU stages that 
>> occur
>> before anything even gets sent to the GPU.
>>
>
> Precisely, there is no guarantee of performance if you call these APIs
> with an array of Swift tuples.
>

 which is exactly why i support a dedicated language-level vector type
 which guarantees contiguous, fixed storage, and which the compiler knows
 about so it can vectorize operations on them.

>>>
>>> That's an entirely separate discussion.
>>>
>>>
 tuples right now try to fill too many roles and that makes life
 difficult for both the compiler and the programmer. however, until then, we
 need some kind of common, fixed layout currency type for vector data, and
 by implementation-detail, *tuples are our best option* since for some
 reason everyone is so opposed to the simple solution of baking vec2,
 vec3, … vec5 into the language and the generic integer Vector
 solution everyone wants likely isn’t going to materialize for the
 foreseeable future.

>>>
>>> Disagree. If you want a particular memory layout, define your type in C.
>>> Swift's interop story is very good, and your type will have a fixed layout
>>> forever.
>>>
>>
>> “*write it in c and import it*” is *not* a solution,, it is a workaround.
>>
>
> Yes, that’s what we’re talking about here: workarounds to lack of a fixed
> layout type. I’m saying C is the “best option” workaround, not tuples.
>
> plus since it lives across the module boundary, it’s effectively opaque to
>> compiler optimizations.
>>
> What sorts of optimizations are you referring to? Recall that we are
> talking about taking a value and unsafe bitcasting for the purposes of
> calling other C APIs.
>
> you misunderstand the use-case. C and C APIs usually don’t show up in the
story until the very last step, when you send the buffer to the drawing
library (cairo, opengl, etc). all the stages that come before are swift and
involve passing data between two swift interfaces.
___
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

[Joe Groff via swift-evolution]

> On Nov 28, 2017, at 10:52 AM, Vladimir.S  wrote:
> 
> On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:
>>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
 > wrote:
 
 when SE-185 
 
  went through swift evolution, it was agreed that the next logical step 
  is 
 synthesizing these conformances for tuple types, though it was left out of 
 the original proposal to avoid mission creep. I think now is the time to 
 start thinking about this. i’m also tacking on Comparable to the other two 
 protocols because there is precedent in the language from SE-15 
 
  that tuple comparison is something that makes sense to write.
 
 EHC conformance is even more important for tuples than it is for structs 
 because tuples effectively have no workaround whereas in structs, you 
 could just manually implement the conformance. 
>>> 
>>> In my opinion, you’re approaching this from the wrong direction.  The 
>>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>>> they could, synthesizing these conformances would be straight-forward.
>> It would be a tractable intermediate problem to introduce built-in 
>> conformances for tuples (and perhaps metatypes) to 
>> Equatable/Hashable/Comparable without breaching the more general topic of 
>> allowing these types to have general protocol conformances. I think that 
>> would cover the highest-value use cases.
> 
> So, shouldn't we do this first step ASAP and then design a good common 
> solution to allow tuples/metatypes/funcs to confirm to custom protocols in 
> some next version of Swift?
> I really believe this is the good practical decision and will be supported by 
> community if such proposal will be on the table.
> Is there any drawback in such step?

The expected behavior of tuple Equatable/Hashable/Comparable seems obvious to 
me (though I could well be missing something), and any behavior we hardcode 
should be naturally replaceable by a generalized conformance mechanism, so it's 
primarily a "small matter of implementation". There would be some 
implementation cost to managing the special case in the compiler and runtime; 
the tradeoff seems worth it to me in this case, but others might reasonably 
disagree. Not speaking for the entire core team, I would personally support 
considering a proposal and implementation for builtin tuple 
Equatable/Hashable/Comparable conformance.

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

[Vladimir.S via swift-evolution]

On 27.11.2017 20:28, Joe Groff via swift-evolution wrote:



On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution > wrote:



On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution > wrote:


when SE-185  
went through swift evolution, it was agreed that the next logical step 
 is synthesizing these conformances for tuple 
types, though it was left out of the original proposal to avoid mission creep. I think now is the time to start 
thinking about this. i’m also tacking on Comparable to the other two protocols because there is precedent in the 
language from SE-15 
 that tuple 
comparison is something that makes sense to write.


EHC conformance is even more important for tuples than it is for structs because tuples effectively have no 
workaround whereas in structs, you could just manually implement the conformance. 


In my opinion, you’re approaching this from the wrong direction.  The fundamental problem here is that tuples can’t 
conform to a protocol.  If they could, synthesizing these conformances would be straight-forward.


It would be a tractable intermediate problem to introduce built-in conformances for tuples (and perhaps metatypes) to 
Equatable/Hashable/Comparable without breaching the more general topic of allowing these types to have general protocol 
conformances. I think that would cover the highest-value use cases.


So, shouldn't we do this first step ASAP and then design a good common solution to allow tuples/metatypes/funcs to 
confirm to custom protocols in some next version of Swift?
I really believe this is the good practical decision and will be supported by community if such proposal will be on the 
table.

Is there any drawback in such step?

Vladimir.



-Joe



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


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

[swift-evolution] [Accepted] SE-0190 - Target environment platform condition

[Ted Kremenek via swift-evolution]

Hello Swift Community,

The review of of “SE-190: Target environment platform condition” ran from 
November 16 to 24, 2017. This proposal has been accepted.

During the review, support for the enhancement was unanimous.  There were some 
questions during the review about the capabilities of this feature. Graydon 
explained that his is largely surfacing target environment information from the 
target triple, which can be flexibly used in many circumstances.

Thanks to everyone who participated in the review.

Ted
Review Manager

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

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Paul Cantrell via swift-evolution]

I’m not sure this solves the Ruby ergonomics problem. Picking up from an 
earlier thread:

Chris wrote:
> Paul wrote:
>> An “always use parens” bridge to Ruby has bad ergonomics
>> Zero-arg Ruby methods are a mixture of property-like things that would 
>> certainly not use parens in Swift, and function-like things that certainly 
>> would:
>> 
>> // Idiomatic Swift:
>> post.author.name.reversed()
>> 
>> // Swift bridging to Ruby…
>> 
>> // …if no-args methods •must• use parens:
>> post.author().name().reverse()
>> 
>> // …if no-args methods •can’t• use parens:
>> post.author.name.reverse
>> 
>> If the goal is to make Swift mostly feel like Swift even when bridging to 
>> Ruby, then the bridge needs to support both access forms.
> 
> Ok, that can certainly be implemented by the two proposals I have in flight.  
> No obvious problem there.


Chris, can you elaborate? I think the proposal precludes this; I must be 
missing something!

As I read the proposal, the dynamic member subscript for post.author returns 
either a property value or a DynamicCallable, depending on whether the thing is 
a property or a method — but post.author and post.author() would both look 
identical to that subscript implementation, and there’s no distinction on the 
Ruby side, so the subscript can’t know which one to return.

The getter could return something that is both a dynamic callable and has 
dynamic members that lazily make the implicit method call. But this has two 
serious problems:

1. The necessarily lazy evaluation of the property value leads to nightmare 
scenarios:

post.author = sally
let oldAuthor = post.author()
post.author = fred
oldAuthor.name  // "Sally"

// but

post.author = sally
let oldAuthor = post.author
post.author = fred
oldAuthor.name  // "Fred"

2. This precludes bridging to Swift types, e.g. Ruby strings → Swift strings.

Therefore it seems the proposal forces post.author().name().reverse(). 
Something I'm missing?

Cheers,

Paul


> On Nov 27, 2017, at 12:04 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> I’d like to formally propose the inclusion of user-defined dynamic member 
> lookup types.
> 
> Here is my latest draft of the proposal:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> https://github.com/apple/swift-evolution/pull/768
> 
> An implementation of this design is available here:
> https://github.com/apple/swift/pull/13076
> 
> The implementation is straight-forward and (IMO) non-invasive in the compiler.
> 
> -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] Make Optional, Array, and Dictionary conditionally Equatable

[Douglas Gregor via swift-evolution]

> On Nov 26, 2017, at 9:21 PM, John McCall  wrote:
> 
>> 
>> On Nov 22, 2017, at 1:08 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> 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. 
> 
> Agreed.  I think bringing it up here and letting it "pass by acclamation" is 
> the appropriate process; doing a separate proposal would be a waste.

To close the loop here, the core team has agreed to this as an amendment to 
SE-0143, and the changed has been merged here:

https://github.com/apple/swift-evolution/pull/769

and we’ve merged the change into the Swift standard library for Swift 4.1, here:

https://github.com/apple/swift/pull/13046

- Doug

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

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Matthew Johnson via swift-evolution]

> On Nov 28, 2017, at 11:40 AM, Tony Allevato  wrote:
> 
> 
> 
> On Tue, Nov 28, 2017 at 9:16 AM Matthew Johnson  > wrote:
>> On Nov 28, 2017, at 11:01 AM, Tony Allevato > > wrote:
>> 
>> 
>> 
>> On Tue, Nov 28, 2017 at 8:45 AM Matthew Johnson > > wrote:
>>> On Nov 28, 2017, at 10:06 AM, Tony Allevato >> > wrote:
>>> 
>>> 
>>> 
>>> On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov >> > wrote:
>>> Hi Tony,
>>> 
>>> So if my understanding is correct, the basic proposal is the following:
>>> 
>>> func id(t: T ?= T.defaultValue) { return t }
>>> 
>>> extension Int { static var defaultValue = 0 }
>>> 
>>> extension String { static var defaultValue = “” }
>>> 
>>> id() as Int // returns 0
>>> id() as String // returns “”
>>> id() as SomeRandomType // fails to type check — no default argument
>>> 
>>> I don’t understand what would happen if the caller is itself generic 
>>> though, for example:
>>> 
>>> callsID(_ t: T) {
>>>   _ = id() as T
>>> }
>>> 
>>> It appears that body of callsID() itself cannot type check without 
>>> knowledge of the concrete T that will be used with this function.
>>> 
>>> Thanks for bringing up this example, Slava.
>>> 
>>> Unless I'm misunderstanding, the issue you're describing is inherent to the 
>>> *problem* described in the original post, not to any specific hypothetical 
>>> syntax for adding the default arguments, correct? In other words, if this 
>>> was written using extensions as can be done today:
>>> 
>>> ```
>>> struct Foo {
>>>   func id(t: T) -> T { return t }
>>> }
>>> 
>>> extension Foo where T == Void {
>>>   func id() -> T { return () }
>>> }
>>> 
>>> extension Foo where T == Int {
>>>   func id() -> T { return 0 }
>>> }
>>> 
>>> callsID(_ t: T) {
>>>   _ = Foo().id() as T// mark
>>> }
>>> ```
>>> 
>>> The compiler would still reject the marked line because there's no 
>>> guarantee that T is one of the types that has the necessary overload.
>>> 
>>> But now that you've mentioned it, it does have me thinking that this 
>>> problem might be better left to extensions. In one sense, default arguments 
>>> are a kind of "overload synthesis”,
>> 
>> They appear to callers as if they were overloads but I think it’s important 
>> that they actually do so *without* introducing an overload.  Reducing the 
>> size of an overload set is good for users, library authors and the compiler. 
>>  The benefits that come to all parties when the size of an overload set is 
>> reduced is the primary reason I started this thread.
>> 
>>> but on the other hand, there's an expectation that the default value 
>>> expression is of a single type (or set of related types) known at compile 
>>> time. Even if it's generic, it still must be expressed in terms of whatever 
>>> constraints are present on that generic type—you can't use a disjunction of 
>>> types, but instead have to have a common protocol that would provide some 
>>> operation.
>> 
>> This should not change for any given default value expression.  This thread 
>> doesn’t discuss changing that.  I discusses the ability to constrain the 
>> presence of a default value expression.
>> 
>> But that's exactly the distinction that I'm driving at—the more I think 
>> about it, the more I have difficulty expressing it cleanly and I think 
>> that's because these aren't the same as default arguments—they really are 
>> distinct overloads because you're talking about the presence or absence of 
>> an argument based on specific constraints instead of something that applies 
>> to the function uniformly for all possible types that satisfy the 
>> constraint. So what I'm suggesting is that maybe conflating this concept 
>> with default arguments is the wrong approach after all.
>> 
>>  
>>  While it would be useful to allow multiple default value expressions for 
>> different constraints the most common case will be a single constrained 
>> default value expression for any given argument.  We could just allow a 
>> trailing where clause on the default value expression itself like this:
>> 
>> func makeResource(
>> with configuration: Configuration = () where Configuration == Void, 
>> actionHandler: @escaping (Action) -> Void = { _ in } where Action == 
>> Never
>> )
>> 
>> That addresses the most common cases for this feature with a fairly obvious 
>> and direct syntax.
>> 
>> Allowing only one constraint seems arbitrary and I imagine that the 
>> immediately following question would be "what if I want more than one?" I 
>> wouldn't want to address only part of the problem. My ICU example further up 
>> in the thread shows a scenario where I would want defaults for two distinct 
>> types (if I also wanted to publicize the general 

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Tony Allevato via swift-evolution]

On Tue, Nov 28, 2017 at 9:16 AM Matthew Johnson 
wrote:

> On Nov 28, 2017, at 11:01 AM, Tony Allevato 
> wrote:
>
>
>
> On Tue, Nov 28, 2017 at 8:45 AM Matthew Johnson 
> wrote:
>
>> On Nov 28, 2017, at 10:06 AM, Tony Allevato 
>> wrote:
>>
>>
>>
>> On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov  wrote:
>>
>>> Hi Tony,
>>>
>>> So if my understanding is correct, the basic proposal is the following:
>>>
>>> func id(t: T ?= T.defaultValue) { return t }
>>>
>>> extension Int { static var defaultValue = 0 }
>>>
>>> extension String { static var defaultValue = “” }
>>>
>>> id() as Int // returns 0
>>> id() as String // returns “”
>>> id() as SomeRandomType // fails to type check — no default argument
>>>
>>> I don’t understand what would happen if the caller is itself generic
>>> though, for example:
>>>
>>> callsID(_ t: T) {
>>>   _ = id() as T
>>> }
>>>
>>> It appears that body of callsID() itself cannot type check without
>>> knowledge of the concrete T that will be used with this function.
>>>
>>
>> Thanks for bringing up this example, Slava.
>>
>> Unless I'm misunderstanding, the issue you're describing is inherent to
>> the *problem* described in the original post, not to any specific
>> hypothetical syntax for adding the default arguments, correct? In other
>> words, if this was written using extensions as can be done today:
>>
>> ```
>> struct Foo {
>>   func id(t: T) -> T { return t }
>> }
>>
>> extension Foo where T == Void {
>>   func id() -> T { return () }
>> }
>>
>> extension Foo where T == Int {
>>   func id() -> T { return 0 }
>> }
>>
>> callsID(_ t: T) {
>>   _ = Foo().id() as T// mark
>> }
>> ```
>>
>> The compiler would still reject the marked line because there's no
>> guarantee that T is one of the types that has the necessary overload.
>>
>> But now that you've mentioned it, it does have me thinking that this
>> problem might be better left to extensions. In one sense, default arguments
>> are a kind of "overload synthesis”,
>>
>>
>> They appear to callers as if they were overloads but I think it’s
>> important that they actually do so *without* introducing an overload.
>> Reducing the size of an overload set is good for users, library authors and
>> the compiler.  The benefits that come to all parties when the size of an
>> overload set is reduced is the primary reason I started this thread.
>>
>> but on the other hand, there's an expectation that the default value
>> expression is of a single type (or set of related types) known at compile
>> time. Even if it's generic, it still must be expressed in terms of whatever
>> constraints are present on that generic type—you can't use a disjunction of
>> types, but instead have to have a common protocol that would provide some
>> operation.
>>
>>
>> This should not change for any given default value expression.  This
>> thread doesn’t discuss changing that.  I discusses the ability to constrain
>> the presence of a default value expression.
>>
>
> But that's exactly the distinction that I'm driving at—the more I think
> about it, the more I have difficulty expressing it cleanly and I think
> that's because these aren't the same as default arguments—they really are
> distinct overloads because you're talking about the presence or absence of
> an argument based on specific constraints instead of something that applies
> to the function uniformly for all possible types that satisfy the
> constraint. So what I'm suggesting is that maybe conflating this concept
> with default arguments is the wrong approach after all.
>
>
>
>>  While it would be useful to allow multiple default value expressions for
>> different constraints the most common case will be a single constrained
>> default value expression for any given argument.  We could just allow a
>> trailing where clause on the default value expression itself like this:
>>
>> func makeResource(
>> with configuration: Configuration = () where Configuration == Void,
>> actionHandler: @escaping (Action) -> Void = { _ in } where Action ==
>> Never
>> )
>>
>> That addresses the most common cases for this feature with a fairly
>> obvious and direct syntax.
>>
>
> Allowing only one constraint seems arbitrary and I imagine that the
> immediately following question would be "what if I want more than one?" I
> wouldn't want to address only part of the problem. My ICU example further
> up in the thread shows a scenario where I would want defaults for two
> distinct types (if I also wanted to publicize the general initializer to
> everyone).
>
>
> Did you really mean “only one constraint” here?  Or did you mean “only one
> default value expression”?  These are very different.  I would not want to
> restrict the number of constraints.  What I am suggesting is that limiting
> this to a single (possibly constrained) default value expression presents a
> relatively obvious syntactic 

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

[Tony Allevato via swift-evolution]

On Mon, Nov 27, 2017 at 5:34 PM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now
> and runs through December 3, 2017. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
>
> Reply text
>
> Other replies
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>
> Emphatically support.


>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Absolutely. In Swift's earlier days I tried writing a handful of
interesting collection algorithms as generally as possible, but I think I
almost always found myself adding "where IndexDistance == Int" to each one.
Once you start to do anything more interesting than linear traversal (e.g.,
binary search or percentiles), you really need to be working with concrete
integral types.

I've certainly been one on this list advocating for protocols to be "no
more specific than they need to be", and it might be possible to get
further along in the above cases nowadays by constraining to Numeric or
BinaryInteger—I haven't tried since it was introduced—but I'm not sure that
alone holds its weight. If other stdlib algorithms would break with non-Int
distances, the increase in difficultly of writing generic collection
algorithms probably isn't worth it.


>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes. It makes collection algorithms more approachable.


>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> Read the proposal and loosely followed the earlier e-mail discussion.


> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
> ___
> 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] [Pre-pitch] Conditional default arguments

[Matthew Johnson via swift-evolution]

> On Nov 28, 2017, at 11:01 AM, Tony Allevato  wrote:
> 
> 
> 
> On Tue, Nov 28, 2017 at 8:45 AM Matthew Johnson  > wrote:
>> On Nov 28, 2017, at 10:06 AM, Tony Allevato > > wrote:
>> 
>> 
>> 
>> On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov > > wrote:
>> Hi Tony,
>> 
>> So if my understanding is correct, the basic proposal is the following:
>> 
>> func id(t: T ?= T.defaultValue) { return t }
>> 
>> extension Int { static var defaultValue = 0 }
>> 
>> extension String { static var defaultValue = “” }
>> 
>> id() as Int // returns 0
>> id() as String // returns “”
>> id() as SomeRandomType // fails to type check — no default argument
>> 
>> I don’t understand what would happen if the caller is itself generic though, 
>> for example:
>> 
>> callsID(_ t: T) {
>>   _ = id() as T
>> }
>> 
>> It appears that body of callsID() itself cannot type check without knowledge 
>> of the concrete T that will be used with this function.
>> 
>> Thanks for bringing up this example, Slava.
>> 
>> Unless I'm misunderstanding, the issue you're describing is inherent to the 
>> *problem* described in the original post, not to any specific hypothetical 
>> syntax for adding the default arguments, correct? In other words, if this 
>> was written using extensions as can be done today:
>> 
>> ```
>> struct Foo {
>>   func id(t: T) -> T { return t }
>> }
>> 
>> extension Foo where T == Void {
>>   func id() -> T { return () }
>> }
>> 
>> extension Foo where T == Int {
>>   func id() -> T { return 0 }
>> }
>> 
>> callsID(_ t: T) {
>>   _ = Foo().id() as T// mark
>> }
>> ```
>> 
>> The compiler would still reject the marked line because there's no guarantee 
>> that T is one of the types that has the necessary overload.
>> 
>> But now that you've mentioned it, it does have me thinking that this problem 
>> might be better left to extensions. In one sense, default arguments are a 
>> kind of "overload synthesis”,
> 
> They appear to callers as if they were overloads but I think it’s important 
> that they actually do so *without* introducing an overload.  Reducing the 
> size of an overload set is good for users, library authors and the compiler.  
> The benefits that come to all parties when the size of an overload set is 
> reduced is the primary reason I started this thread.
> 
>> but on the other hand, there's an expectation that the default value 
>> expression is of a single type (or set of related types) known at compile 
>> time. Even if it's generic, it still must be expressed in terms of whatever 
>> constraints are present on that generic type—you can't use a disjunction of 
>> types, but instead have to have a common protocol that would provide some 
>> operation.
> 
> This should not change for any given default value expression.  This thread 
> doesn’t discuss changing that.  I discusses the ability to constrain the 
> presence of a default value expression.
> 
> But that's exactly the distinction that I'm driving at—the more I think about 
> it, the more I have difficulty expressing it cleanly and I think that's 
> because these aren't the same as default arguments—they really are distinct 
> overloads because you're talking about the presence or absence of an argument 
> based on specific constraints instead of something that applies to the 
> function uniformly for all possible types that satisfy the constraint. So 
> what I'm suggesting is that maybe conflating this concept with default 
> arguments is the wrong approach after all.
> 
>  
>  While it would be useful to allow multiple default value expressions for 
> different constraints the most common case will be a single constrained 
> default value expression for any given argument.  We could just allow a 
> trailing where clause on the default value expression itself like this:
> 
> func makeResource(
> with configuration: Configuration = () where Configuration == Void, 
> actionHandler: @escaping (Action) -> Void = { _ in } where Action == Never
> )
> 
> That addresses the most common cases for this feature with a fairly obvious 
> and direct syntax.
> 
> Allowing only one constraint seems arbitrary and I imagine that the 
> immediately following question would be "what if I want more than one?" I 
> wouldn't want to address only part of the problem. My ICU example further up 
> in the thread shows a scenario where I would want defaults for two distinct 
> types (if I also wanted to publicize the general initializer to everyone).

Did you really mean “only one constraint” here?  Or did you mean “only one 
default value expression”?  These are very different.  I would not want to 
restrict the number of constraints.  What I am suggesting is that limiting this 
to a single (possibly constrained) default value expression presents a 
relatively obvious syntactic 

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Tony Allevato via swift-evolution]

On Tue, Nov 28, 2017 at 8:45 AM Matthew Johnson 
wrote:

> On Nov 28, 2017, at 10:06 AM, Tony Allevato 
> wrote:
>
>
>
> On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov  wrote:
>
>> Hi Tony,
>>
>> So if my understanding is correct, the basic proposal is the following:
>>
>> func id(t: T ?= T.defaultValue) { return t }
>>
>> extension Int { static var defaultValue = 0 }
>>
>> extension String { static var defaultValue = “” }
>>
>> id() as Int // returns 0
>> id() as String // returns “”
>> id() as SomeRandomType // fails to type check — no default argument
>>
>> I don’t understand what would happen if the caller is itself generic
>> though, for example:
>>
>> callsID(_ t: T) {
>>   _ = id() as T
>> }
>>
>> It appears that body of callsID() itself cannot type check without
>> knowledge of the concrete T that will be used with this function.
>>
>
> Thanks for bringing up this example, Slava.
>
> Unless I'm misunderstanding, the issue you're describing is inherent to
> the *problem* described in the original post, not to any specific
> hypothetical syntax for adding the default arguments, correct? In other
> words, if this was written using extensions as can be done today:
>
> ```
> struct Foo {
>   func id(t: T) -> T { return t }
> }
>
> extension Foo where T == Void {
>   func id() -> T { return () }
> }
>
> extension Foo where T == Int {
>   func id() -> T { return 0 }
> }
>
> callsID(_ t: T) {
>   _ = Foo().id() as T// mark
> }
> ```
>
> The compiler would still reject the marked line because there's no
> guarantee that T is one of the types that has the necessary overload.
>
> But now that you've mentioned it, it does have me thinking that this
> problem might be better left to extensions. In one sense, default arguments
> are a kind of "overload synthesis”,
>
>
> They appear to callers as if they were overloads but I think it’s
> important that they actually do so *without* introducing an overload.
> Reducing the size of an overload set is good for users, library authors and
> the compiler.  The benefits that come to all parties when the size of an
> overload set is reduced is the primary reason I started this thread.
>
> but on the other hand, there's an expectation that the default value
> expression is of a single type (or set of related types) known at compile
> time. Even if it's generic, it still must be expressed in terms of whatever
> constraints are present on that generic type—you can't use a disjunction of
> types, but instead have to have a common protocol that would provide some
> operation.
>
>
> This should not change for any given default value expression.  This
> thread doesn’t discuss changing that.  I discusses the ability to constrain
> the presence of a default value expression.
>

But that's exactly the distinction that I'm driving at—the more I think
about it, the more I have difficulty expressing it cleanly and I think
that's because these aren't the same as default arguments—they really are
distinct overloads because you're talking about the presence or absence of
an argument based on specific constraints instead of something that applies
to the function uniformly for all possible types that satisfy the
constraint. So what I'm suggesting is that maybe conflating this concept
with default arguments is the wrong approach after all.



>  While it would be useful to allow multiple default value expressions for
> different constraints the most common case will be a single constrained
> default value expression for any given argument.  We could just allow a
> trailing where clause on the default value expression itself like this:
>
> func makeResource(
> with configuration: Configuration = () where Configuration == Void,
> actionHandler: @escaping (Action) -> Void = { _ in } where Action ==
> Never
> )
>
> That addresses the most common cases for this feature with a fairly
> obvious and direct syntax.
>

Allowing only one constraint seems arbitrary and I imagine that the
immediately following question would be "what if I want more than one?" I
wouldn't want to address only part of the problem. My ICU example further
up in the thread shows a scenario where I would want defaults for two
distinct types (if I also wanted to publicize the general initializer to
everyone).



>  It also avoids the potential ambiguity that could arise from allowing
> multiple defaults with different (potentially overlapping) constraints.
>

That would be no different than the existing problem of multiple overloads
with different (potentially overlapping) constraints, right? If what you're
looking for is a way to have the compiler automatically synthesize
overloads in extensions for you based on certain constraints, I would
expect the same restrictions to apply as if you had explicitly written them
out long-form.



>
>
>
>>
>> Slava
>>
>> On Nov 27, 2017, at 4:10 PM, Tony Allevato via swift-evolution <
>> 

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Matthew Johnson via swift-evolution]

> On Nov 28, 2017, at 10:06 AM, Tony Allevato  wrote:
> 
> 
> 
> On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov  > wrote:
> Hi Tony,
> 
> So if my understanding is correct, the basic proposal is the following:
> 
> func id(t: T ?= T.defaultValue) { return t }
> 
> extension Int { static var defaultValue = 0 }
> 
> extension String { static var defaultValue = “” }
> 
> id() as Int // returns 0
> id() as String // returns “”
> id() as SomeRandomType // fails to type check — no default argument
> 
> I don’t understand what would happen if the caller is itself generic though, 
> for example:
> 
> callsID(_ t: T) {
>   _ = id() as T
> }
> 
> It appears that body of callsID() itself cannot type check without knowledge 
> of the concrete T that will be used with this function.
> 
> Thanks for bringing up this example, Slava.
> 
> Unless I'm misunderstanding, the issue you're describing is inherent to the 
> *problem* described in the original post, not to any specific hypothetical 
> syntax for adding the default arguments, correct? In other words, if this was 
> written using extensions as can be done today:
> 
> ```
> struct Foo {
>   func id(t: T) -> T { return t }
> }
> 
> extension Foo where T == Void {
>   func id() -> T { return () }
> }
> 
> extension Foo where T == Int {
>   func id() -> T { return 0 }
> }
> 
> callsID(_ t: T) {
>   _ = Foo().id() as T// mark
> }
> ```
> 
> The compiler would still reject the marked line because there's no guarantee 
> that T is one of the types that has the necessary overload.
> 
> But now that you've mentioned it, it does have me thinking that this problem 
> might be better left to extensions. In one sense, default arguments are a 
> kind of "overload synthesis”,

They appear to callers as if they were overloads but I think it’s important 
that they actually do so *without* introducing an overload.  Reducing the size 
of an overload set is good for users, library authors and the compiler.  The 
benefits that come to all parties when the size of an overload set is reduced 
is the primary reason I started this thread.

> but on the other hand, there's an expectation that the default value 
> expression is of a single type (or set of related types) known at compile 
> time. Even if it's generic, it still must be expressed in terms of whatever 
> constraints are present on that generic type—you can't use a disjunction of 
> types, but instead have to have a common protocol that would provide some 
> operation.

This should not change for any given default value expression.  This thread 
doesn’t discuss changing that.  I discusses the ability to constrain the 
presence of a default value expression.  While it would be useful to allow 
multiple default value expressions for different constraints the most common 
case will be a single constrained default value expression for any given 
argument.  We could just allow a trailing where clause on the default value 
expression itself like this:

func makeResource(
with configuration: Configuration = () where Configuration == Void, 
actionHandler: @escaping (Action) -> Void = { _ in } where Action == Never
)

That addresses the most common cases for this feature with a fairly obvious and 
direct syntax.  It also avoids the potential ambiguity that could arise from 
allowing multiple defaults with different (potentially overlapping) constraints.


>  
> 
> Slava
> 
>> On Nov 27, 2017, at 4:10 PM, Tony Allevato via swift-evolution 
>> > wrote:
>> 
>> I totally agree that that's a good rule in general—I'm not 100% comfortable 
>> making an exception to it for this, but I wanted to start a discussion about 
>> a different approach than had been considered so far.
>> 
>> The idea of forcing the user to acknowledge the explicitness of SFINAE with 
>> a strawman syntax `=?` instead of `=` was a thought experiment to bridge the 
>> wild-west-C++ world of templates and Swift's stricter generics, but I can 
>> definitely understand if even that kind of approach is something that the 
>> core team (who are far more familiar with the C++ side of that coin than I 
>> am) doesn't wish to support. As was pointed out, it's not something Swift 
>> supports anywhere else today.
>> 
>> If we look at it from that point of view, where such a semantic treatment of 
>> generics would not be supported, I think it becomes a lot harder to 
>> rationalize treating this as "default arguments". What you really do have 
>> (and what writing it as constrained extensions makes clear) is additional 
>> overloads, because they only apply to certain subsets of types. If that's 
>> the case, maybe it's the wrong approach to try to turn overloads into 
>> "partial default values".
> 

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Tony Allevato via swift-evolution]

On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov  wrote:

> Hi Tony,
>
> So if my understanding is correct, the basic proposal is the following:
>
> func id(t: T ?= T.defaultValue) { return t }
>
> extension Int { static var defaultValue = 0 }
>
> extension String { static var defaultValue = “” }
>
> id() as Int // returns 0
> id() as String // returns “”
> id() as SomeRandomType // fails to type check — no default argument
>
> I don’t understand what would happen if the caller is itself generic
> though, for example:
>
> callsID(_ t: T) {
>   _ = id() as T
> }
>
> It appears that body of callsID() itself cannot type check without
> knowledge of the concrete T that will be used with this function.
>

Thanks for bringing up this example, Slava.

Unless I'm misunderstanding, the issue you're describing is inherent to the
*problem* described in the original post, not to any specific hypothetical
syntax for adding the default arguments, correct? In other words, if this
was written using extensions as can be done today:

```
struct Foo {
  func id(t: T) -> T { return t }
}

extension Foo where T == Void {
  func id() -> T { return () }
}

extension Foo where T == Int {
  func id() -> T { return 0 }
}

callsID(_ t: T) {
  _ = Foo().id() as T// mark
}
```

The compiler would still reject the marked line because there's no
guarantee that T is one of the types that has the necessary overload.

But now that you've mentioned it, it does have me thinking that this
problem might be better left to extensions. In one sense, default arguments
are a kind of "overload synthesis", but on the other hand, there's an
expectation that the default value expression is of a single type (or set
of related types) known at compile time. Even if it's generic, it still
must be expressed in terms of whatever constraints are present on that
generic type—you can't use a disjunction of types, but instead have to have
a common protocol that would provide some operation.


>
> Slava
>
> On Nov 27, 2017, at 4:10 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I totally agree that that's a good rule in general—I'm not 100%
> comfortable making an exception to it for this, but I wanted to start a
> discussion about a different approach than had been considered so far.
>
> The idea of forcing the user to acknowledge the explicitness of SFINAE
> with a strawman syntax `=?` instead of `=` was a thought experiment to
> bridge the wild-west-C++ world of templates and Swift's stricter generics,
> but I can definitely understand if even that kind of approach is something
> that the core team (who are far more familiar with the C++ side of that
> coin than I am) doesn't wish to support. As was pointed out, it's not
> something Swift supports anywhere else today.
>
> If we look at it from that point of view, where such a semantic treatment
> of generics would not be supported, I think it becomes a lot harder to
> rationalize treating this as "default arguments". What you really do have
> (and what writing it as constrained extensions makes clear) is additional
> overloads, because they only apply to certain subsets of types. If that's
> the case, maybe it's the wrong approach to try to turn overloads into
> "partial default values".
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

[Matthew Johnson via swift-evolution]

> On Nov 28, 2017, at 12:34 AM, Slava Pestov  wrote:
> 
> 
> 
>> On Nov 27, 2017, at 3:38 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> You are effectively proposing that in this very narrow case we perform 
>> overload resolution on a symbol in a generic type context *after* the 
>> generic type has been replaced with a concrete type. 
> 
> Keep in mind that in general, this would require runtime support — we don’t 
> always know the concrete substitution for a generic parameter at compile 
> time, especially in the presence of separate compilation (but even without, 
> for instance when optimizations are not enabled or unable to recover concrete 
> type information).

Thanks for mentioning that.  IMO, it rules out this approach as it means we 
wouldn’t always know statically whether a default argument is available.  C++ 
gets away with it because templates are always substituted during compilation 
and that isn’t true for Swift generics.

> 
> Slava

___
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

[Tino Heth via swift-evolution]

I think this thread derailed quite a bit — it might have even been a good thing 
that some discussion accidentally went off-list ;-)

Personally, I think it's nice if tuples and structs would converge more, so 
that either struct is seen as an extension of the tuple-concept, or tuple is 
considered to be an (restricted) anonymous struct.
E.g.

struct StructPoint {
let x: Float
let y: Float
}

typealias TuplePoint = (x: Float, y: Float)

would more or less have the same abilities (allowing extensions and 
protocol-conformance).
Constructors for tuples would afaics be easy, and maybe it would even be 
possible to initialize some structs from tuple-literals.

___
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

[Xiaodi Wu via swift-evolution]

On Tue, Nov 28, 2017 at 00:32 Kelvin Ma  wrote:

> On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu  wrote:
>
>> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma  wrote:
>>
>>>
>>>
>>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu  wrote:
>>>
 On Mon, Nov 27, 2017 at 15:46 Taylor Swift 
 wrote:

> they use packed buffers of floats, which for type safety are better
> rebound to a structured type. right now (Float, Float, Float) works 
> because
> the tuple is laid out contiguously and the GPU can’t tell the difference
> but it’s not guaranteed. also you’re ignoring all the CPU stages that 
> occur
> before anything even gets sent to the GPU.
>

 Precisely, there is no guarantee of performance if you call these APIs
 with an array of Swift tuples.

>>>
>>> which is exactly why i support a dedicated language-level vector type
>>> which guarantees contiguous, fixed storage, and which the compiler knows
>>> about so it can vectorize operations on them.
>>>
>>
>> That's an entirely separate discussion.
>>
>>
>>> tuples right now try to fill too many roles and that makes life
>>> difficult for both the compiler and the programmer. however, until then, we
>>> need some kind of common, fixed layout currency type for vector data, and
>>> by implementation-detail, *tuples are our best option* since for some
>>> reason everyone is so opposed to the simple solution of baking vec2,
>>> vec3, … vec5 into the language and the generic integer Vector
>>> solution everyone wants likely isn’t going to materialize for the
>>> foreseeable future.
>>>
>>
>> Disagree. If you want a particular memory layout, define your type in C.
>> Swift's interop story is very good, and your type will have a fixed layout
>> forever.
>>
>
> “*write it in c and import it*” is *not* a solution,, it is a workaround.
>

Yes, that’s what we’re talking about here: workarounds to lack of a fixed
layout type. I’m saying C is the “best option” workaround, not tuples.

plus since it lives across the module boundary, it’s effectively opaque to
> compiler optimizations.
>
What sorts of optimizations are you referring to? Recall that we are
talking about taking a value and unsafe bitcasting for the purposes of
calling other C APIs.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

[Daniel Vollmer via swift-evolution]

Hi list,

> On 28. Nov 2017, at 02:34, Douglas Gregor via swift-evolution 
>  wrote:
> 
> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now 
> and runs through December 3, 2017. The proposal is available here:
> 
>   • What is your evaluation of the proposal?

+1.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes, the motivation of “less difficulty of programming against generic 
collections” is good enough.

>   • Does this proposal fit well with the feel and direction of Swift?

I feel it does. Things shouldn’t be generic “just because we can”. Swift has 
made a fairly firm recommendation on integer sizes and signedness, and that 
should continue into index distances in collections.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

C++ often has a difference_type in its containers, but hardly anyone uses that 
correctly (size_t vs difference_type).

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick glance.

Daniel.

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