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

[Jean-Daniel via swift-evolution]

> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution 
>  a écrit :
> 
> Hi Chis, 
> 
> Thank you for pushing this forward.
> 
> My only comment is that on the declaration side it would be great to also 
> have an attribute to communicate that compiler magic is happening.
> 
> Currently it is surprising that a regular looking protocol is providing me so 
> much power.
> 
> Suggestions: 
> 
> @dynamic
> struct PyVal : MemberLookupProtocol {...}
> 
> @dynamic
> struct ParameterSummer : DynamicCallable {...}
> 
> // Error: This type needs the @dynamic attribute.
> class ParamWinter : MyCustomCallableProtocolOrClassOrTypeAlias {...}
> 
> By requiring @dynamic (Or other attribute name), people can know that this is 
> a compiler dynamic declaration and not just some random protocol whose name 
> starts with Dynamic*. :)
> 

I’m not fond of the idea of an attribute. This introduce redundancy. What a 
declaration means if the attribute is missing ?  What this attribute will mean 
on an other declaration ?
If this attribute must be used with the declaration and it can’t be used with 
an other one, then what is the point of having an attribute but to exercice the 
compiler fixit feature 

> @NSManagedObject is another example I like from Core Data.
> https://useyourloaf.com/blog/core-data-code-generation/ 
> 
@NSManageObject apply to normal declarations that have a different meaning when 
this attribute is not present.


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

Re: [swift-evolution] [RFC] Associated type inference

[Dave Abrahams via swift-evolution]

> On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> Associated type inference, which is the process by which the Swift compiler 
> attempts to infer typealiases to satisfy associated-type requirements based 
> on other requirements, has caused both implementation problems and user 
> confusion for a long time. Some of you might remember a previous (failed) 
> attempt to remove this feature from the Swift language, in SE-0108 “Remove 
> associated type inference”. 
> 
> I’m not sure we can remove this feature outright (i.e., the concerns that 
> sank that proposal are still absolutely valid), because it is so very 
> convenient and a lot of user code likely depends on it in some form or other. 
> So, here I’d like to describe the uses of the feature, its current (very 
> problematic) implementation approach, and a half-baked proposal to narrow the 
> scope of associated type inference to something that I think is more 
> tractable. I need help with the design of this feature, because I feel like 
> it’s going to be a delicate balance between implementability and 
> expressiveness.

Aloha, Doug!

> 
> A Motivating Example
> As a motivating example, let’s consider a “minimal” random access collection:
> 
> struct MyCollection {
> var contents: [T]
> }
> 
> extension MyCollection: RandomAccessCollection {
> var startIndex: Int { return contents.startIndex }
> var endIndex: Int { return contents.endIndex }
> subscript(index: Int) -> T { return contents[index] }
> }
> 
> This is actually pretty awesome: by providing just two properties and a 
> subscript, we get the full breadth of the random access collection API! This 
> is relying heavily on associated type inference (for associated type 
> requirements) and default implementations specified on protocol extensions. 
> Without associated type inference, we would have had to write:
> 
> 
> extension MyCollection: RandomAccessCollection {
> typealias Element = T
> typealias Index = Int
> typealias Indices = CountableRange
> typealias Iterator = IndexingIterator
> typealias SubSequence = RandomAccessSlice
> 
> var startIndex: Int { return contents.startIndex }
> var endIndex: Int { return contents.endIndex }
> subscript(index: Int) -> T { return contents[index] }
> }
> 
> where the bolded typealiases are currently inferred. It was worse back when 
> we reviewed SE-0108, because IIRC there were a few underscored associated 
> types (e.g., _Element) that have since been removed. Still, that’s a bit of 
> additional work to define a “minimal” collection, and requires quite a bit 
> more understanding: how do I know to choose IndexingIterator, and 
> CountableRange, and RandomAccessSlice?
> 
> The issue would get worse with, e.g., SE-0174 “Change filter to return an 
> associated type”, which adds an associated type Filtered that almost nobody 
> will ever customize, and isn’t really fundamental to the way collections 
> work. Adding Filtered to the standard library would be a source-breaking 
> change, because users would have to write a typealias giving it its default.
> 
> Associated Type Defaults
> One of the ways in which we avoid having to specify typealiases is to use 
> associated type defaults. For example, the standard library contains 
> associated type defaults for Indices, Iterator, and SubSequence. Let’s focus 
> on Indices:
> 
> protocol Collection : Sequence {
>   associatedtype Indices = DefaultIndices
>   // ...
> }
> 
> protocol BidirectionalCollection : Collection {
>   associatedtype Indices = DefaultBidirectionalIndices
>   // ...
> }
> 
> protocol RandomAccessCollection : BidirectionalCollection {
>   associatedtype Indices = DefaultRandomAccessIndices
>   // ...
> }
> 
> The basic idea here is that different protocols in the hierarchy provide 
> different defaults, and you presumably want the default from the most 
> specific protocol. If I define a type and make it conform to 
> BidirectionalCollection, I’d expect to get DefaultBidirectionalIndices 
> for Indices. If a define a type and make it conform to RandomAccessIterator, 
> I’d expect to get DefaultRandomAccessIndices.
> 
> (Aside: DefaultRandomAccessIndices and DefaultBidirectionalIndices got 
> collapsed into DefaultIndices now that we have conditional conformances for 
> the standard library, but the issues I’m describing remain).
> 
> Associated type defaults seem like a reasonable feature that fits well enough 
> into the design. However, it’s not the only thing in place with our 
> MyCollection example, for which Indices was inferred to CountableRange. How’s 
> that happen?
> 
> Associated Type Inference
> Associated type inference attempts to look at the requirements of a protocol, 
> and then looks into the conforming type for declarations that might satisfy 
> those requirements, and infers associated types 

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

[Nevin Brackett-Rozinsky via swift-evolution]

I have no input on whether or not this dynamism should be added to Swift.

However, *if* we add it, then I strongly prefer that dynamic member lookup
should use the exact same syntax as static member lookup, namely a single
dot. Member lookup is member lookup, the user-facing behavior is the same
is both cases, and we should present a single coherent experience with
maximum elegance and simplicity.

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

[Jose Cheyo Jimenez via swift-evolution]

Hi Chis, 

Thank you for pushing this forward.

My only comment is that on the declaration side it would be great to also have 
an attribute to communicate that compiler magic is happening.

Currently it is surprising that a regular looking protocol is providing me so 
much power.

Suggestions: 

@dynamic
struct PyVal : MemberLookupProtocol {...}

@dynamic
struct ParameterSummer : DynamicCallable {...}

// Error: This type needs the @dynamic attribute.
class ParamWinter : MyCustomCallableProtocolOrClassOrTypeAlias {...}

By requiring @dynamic (Or other attribute name), people can know that this is a 
compiler dynamic declaration and not just some random protocol whose name 
starts with Dynamic*. :)

@NSManagedObject is another example I like from Core Data.
https://useyourloaf.com/blog/core-data-code-generation/ 


- Cheyo



> On Nov 28, 2017, at 8:35 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> 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

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

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

[Dave Abrahams via swift-evolution]

I don’t have much to say about this other than that I think the discussion 
seems way too narrow, focusing on spelling rather than on functionality and 
composability.  I consider the “generic random number library” design to be a 
mostly-solved problem, in the C++ standard library 
(http://en.cppreference.com/w/cpp/numeric/random).  Whatever goes into the 
Swift standard library does not need to have all those features right away, but 
should support being extended into something having the same general shape. IMO 
the right design strategy is to implement and use a Swift version of C++’s 
facilities and only then consider proposing [perhaps a subset of] that design 
for standardization in Swift.

Sent from my iPad

> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution 
>  wrote:
> 
> 
>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Instead, we ought to make clear to users both the features and the 
>> limitations of this API, to encourage use where suitable and to discourage 
>> use where unsuitable.
> 
> I like that you're considering the balance here. I've been lightly following 
> this thread and want to add my thoughts on keeping crypto and 
> pseudorandomness out of the name of at least one random API intended for 
> general use.
> 
> For someone who doesn't know or care about the subtleties of insecure or 
> pseudorandom numbers, I'm not sure that the name insecureRandom is 
> effectively much different than badRandom, at least in terms of the 
> information it conveys to non-experts. To Greg's point, that's the opposite 
> of the signal that the API name should suggest because it's what most people 
> should use most of the time. As you say, this API is being designed for 
> general use.
> 
> There's a cost to adding extra complexity to names, too. I don't think it's 
> far-fetched to suspect that people who find insecureRandom in an autocomplete 
> listing or search will think "Where's the plain random function?"... and then 
> go looking for a community extension that will inevitably provide a trivial 
> alias: func random() { return insecureRandom() }. That's the sort of adoption 
> I'd expect from something for new programmers, like Swift Playgrounds. 
> Someone's introduction to randomness in programming should probably involve 
> no more than a straightforward mapping from the elementary definition, rather 
> than forcing a teaching moment from more advanced math.
> 
> I think there are better places for caveat information than in the API names 
> themselves; documentation being one clear destination. This is in contrast 
> with Unsafe*Pointer, where the safety element is critical enough to be 
> elevated to be more than caveat-level information. You can go really far and 
> create really cool things before these caveats start to apply. Using 
> randomness as a black box in an intro programming environment seems like a 
> much more common scenario than someone attempting to roll their first crypto 
> by only reading API names and hoping for the best.
> 
> -Kyle
> ___
> 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

[Kyle Murray via swift-evolution]

> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Instead, we ought to make clear to users both the features and the 
> limitations of this API, to encourage use where suitable and to discourage 
> use where unsuitable.

I like that you're considering the balance here. I've been lightly following 
this thread and want to add my thoughts on keeping crypto and pseudorandomness 
out of the name of at least one random API intended for general use.

For someone who doesn't know or care about the subtleties of insecure or 
pseudorandom numbers, I'm not sure that the name insecureRandom is effectively 
much different than badRandom, at least in terms of the information it conveys 
to non-experts. To Greg's point, that's the opposite of the signal that the API 
name should suggest because it's what most people should use most of the time. 
As you say, this API is being designed for general use.

There's a cost to adding extra complexity to names, too. I don't think it's 
far-fetched to suspect that people who find insecureRandom in an autocomplete 
listing or search will think "Where's the plain random function?"... and then 
go looking for a community extension that will inevitably provide a trivial 
alias: func random() { return insecureRandom() }. That's the sort of adoption 
I'd expect from something for new programmers, like Swift Playgrounds. 
Someone's introduction to randomness in programming should probably involve no 
more than a straightforward mapping from the elementary definition, rather than 
forcing a teaching moment from more advanced math.

I think there are better places for caveat information than in the API names 
themselves; documentation being one clear destination. This is in contrast with 
Unsafe*Pointer, where the safety element is critical enough to be elevated to 
be more than caveat-level information. You can go really far and create really 
cool things before these caveats start to apply. Using randomness as a black 
box in an intro programming environment seems like a much more common scenario 
than someone attempting to roll their first crypto by only reading API names 
and hoping for the best.

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Dec 2, 2017, at 7:40 PM, Chris Lattner  wrote:
> 
> On Dec 2, 2017, at 2:13 PM, Matthew Johnson  wrote:
>>> For all those reasons, we really do need something like AnyObject dispatch 
>>> if we care about working with dynamically typed languages.  The design I’m 
>>> suggesting carefully cordons this off into its own struct type, so it 
>>> doesn’t infect the rest of the type system, and is non-invasive in the 
>>> compiler.
>> 
>> I am quite familiar with dynamic languages and agree that this is necessary 
>> if we are going to fully open up access to these languages from Swift.
> 
> Ok, then it appears you agree that something like anyobject dispatch is 
> necessary for effective dynamic language interop.
> 
 I strongly urge you to reconsider the decision of that dynamic members 
 must be made available with no indication at usage sites.  An indication 
 of dynamic lookup at usage sites aligns very well (IMO) with the rest of 
 Swift (AnyObject lookup aside) by calling attention to code that requires 
 extra care to get right.
>>> 
>>> I don’t understand this.  The proposal is fully type safe, and this 
>>> approach is completely precedented by AnyObject.  Swift’s type system 
>>> supports many ways to express fallibility, and keeping those decisions 
>>> orthogonal to this proposal is the right thing to do, because it allows the 
>>> author of the type to decide what model makes sense for them.
>> 
>> Allowing the author of the type to choose whether the mechanism is hidden or 
>> visible is exactly what I don’t want to allow.  I think you have the right 
>> design regarding types and semantics - the author chooses.  But I don’t want 
>> these calls to look like ordinary member lookup when I’m reading code.  
>> 
>> They inherently have a much greater chance of failure than ordinary member 
>> lookup.  Further, authors are likely to choose immediate traps or nil IUO as 
>> failure modes as forcing users to deal with Optional on every call is likely 
>> to be untenable.  I believe this behavior should be represented by some kind 
>> of syntax at the usage site.  I don’t believe it is an undue burden.  It 
>> would make the dynamic lookup semantic clear to all readers and would help 
>> to discourage abuse.
> 
> I believe that adding explicit syntax would be counterproductive to your 
> goals, and would not make dynamic lookup syntax more clear.  I assume that 
> you would also want the same thing for DynamicCallable too, and operator 
> overloads, subscripts, and every other operation you perform on these values, 
> since they all have the exact same behavior.
> 
> If we required some syntax even as minimal as “foo.^bar” and "baz^(42)”, that 
> change would turn this (which uses runtime failing or IUO return values like 
> AnyObject):
> 
>   let np = Python.import("numpy")
>   let x = np.array([6, 7, 8])
>   let y =  np.arange(24).reshape(2, 3, 4)
>   
>   let a = np.ones(3, dtype: np.int32)
>   let b = np.linspace(0, pi, 3)
>   let c = a+b
>   let d = np.exp(c)
>   print(d)
> 
> into:
> 
>   let np = Python.import("numpy")
>   let b = np^.array^([6, 7, 8])
>   let y =  np^.arange^(24)^.reshape^(2, 3, 4)
>   
>   let a = np^.ones^(3, dtype: np^.int32)
>   let b = np^.linspace^(0, pi, 3)
>   let c = a+^b
>   let d = np^.exp^(c)
> 
> This does not improve clarity of code, it merely serves to obfuscate logic.  
> It is immediately apparent from the APIs being used, the API style, and the 
> static types (in Xcode or through static declarations) that this is all 
> Python stuff.  

It may be immediately apparent when the types involved are obviously dynamic, 
such as in this example where Python.import is explicitly used.  However, my 
concern is less about the intended use case of dynamic language interop than I 
am that this feature will be generally available to all types in Swift.  

This is big change from AnyObject dispatch.  It opens up the dynamism to types 
and contexts that are not necessarily obviously using dynamic lookup, callable, 
etc.  Maybe this won’t turn out to be a problem in practice but I still think 
it’s a legitimate concern.

> When you start mixing in use of native Swift types like dictionaries 
> (something we want to encourage because they are typed!) you end up with an 
> inconsistent mismash where people would just try adding syntax or applying 
> fixits continuously until the code builds.
> 
> Beyond that, it is counterproductive to your goals, because it means that 
> people are far less likely to use to use optional returns.  Doing so (which 
> produces a safer result) would cause a double tax in syntax, and would be a 
> confusing jumble.  I can’t bring myself to do the whole example above, one 
> line - just converting member lookup syntax but not callable syntax - would 
> end up:
> 
>   let y =  

Re: [swift-evolution] [RFC] Associated type inference

[Howard Lovatt via swift-evolution]

We also know that the current situation isn’t acceptable to a great proposition 
of the community, that is why we are still discussing the issue!

A notable example of reversal of an evolution decision is String’s conformance 
to Collection. Which I think on the 2nd attempt was a much better decision. 

For requiring typedefs for associated types, a fix it and error would be quite 
successful, e.g. Xcode already suggests the typedefs (which I currently accept 
before letting Xcode insert blanks for the missing methods etc.).

-- Howard. 

> On 3 Dec 2017, at 8:15 am, Xiaodi Wu  wrote:
> 
>> On Sat, Dec 2, 2017 at 2:30 PM, Howard Lovatt via swift-evolution 
>>  wrote:
>> Definitely in favour of doing something, I always define the associated 
>> types since I have had so much trouble with the inference.
>> 
>> Personally I would prefer just 1 and 2 and forget 3. I know this would break 
>> a lot of code, but I think we should do that because it is the lesser of the 
>> evils.
> 
> As Doug wrote, an approach that's essentially that was reviewed and rejected 
> in SE-0108. We already know that it's not acceptable to a great proportion of 
> the community.
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> My point is that our entire design process has been geared towards a 
> reasonable, best-effort general-use API: It is being designed by community 
> members who are not specialized in this particular subfield. It is explicitly 
> being design for common, general use cases in mind. And the implementation 
> will come with no guarantee as to suitability for crypto, nor should it have 
> to.

+1.  

Even if we tried to make an RNG for crypto use it would not be widely used for 
crypto because it would not be good enough for someone who really really cares. 
 At the same time, general users would suffer due to the design decisions 
aligned at making it suitable for crypto.

In the end, it would not serve either audience well.  It is better to 
acknowledge up front that the goal of the stdlib is “general use” and optimize 
to ensure that use case is well served.

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

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

[Xiaodi Wu via swift-evolution]

On Sat, Dec 2, 2017 at 19:02 Greg Parker  wrote:

>
> On Dec 2, 2017, at 1:09 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon  > wrote:
>
>> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> That said, I am not sure that this proposal should give any pretense of
>> being suitable for cryptographic use. On implementation, the code will not
>> have been audited for that purpose, although the author very rightly
>> attempts to use the "best" possible sources of entropy available for each
>> platform. Perhaps explicitly _not_ supporting cryptographic operations is
>> the more Swifty way to go (in the sense that, where possible, Swift API
>> design aims to help users avoid footguns).
>>
>>
>> People will use it for crypto whether we want them to or not.
>>
>
> People are going to do all sorts of unanticipated things, sure. But this
> doesn't mean that we shouldn't consider how we may best encourage users to
> avoid _unintentional_ common pitfalls.
>
> There are options to explore here. Consider, for example--and I'm not
> suggesting that we be this verbose, but it is illustrative of the
> trade-offs which are possible to keep in mind--if certain methods were very
> clear that the result is *pseudorandom* and potentially *insecure*:
> `(0..<9).insecurePseudorandomElement`. Clearly, fewer people would use this
> method for crypto.
>
>
> But what *should* they use instead of our API? The OS-provided CSPRNG is
> almost certainly going to be the most secure thing available in the absence
> of specialized hardware. We should not deliberately scare users away from
> our API if there is nothing better on offer.
>

>
It’s not about OS-provided CSPRNG. It’s about the design and implementation
of _this proposal_ on top of the CSPRNG.

Earlier, we discussed how this API should minimize the number of optional
return values to improve user ergonomics. Instead, the returned value
should be a reasonable best-effort at randomness. This is sensible for a
general-use API, but it is unsuitable for a crypto-oriented API.

David Waite criticizes GameplayKit as lacking in crypto-oriented
functions—the implication being that we ought to provide them here. I
disagree. My point is that our entire design process has been geared
towards a reasonable, best-effort general-use API: It is being designed by
community members who are not specialized in this particular subfield. It
is explicitly being design for common, general use cases in mind. And the
implementation will come with no guarantee as to suitability for crypto,
nor should it have to.

Therefore, I reason, we ought not to extend the design with functions that
are explicitly geared towards crypto using primitive operations that we
haven’t audited for such suitability. Instead, we ought to make clear to
users both the features and the limitations of this API, to encourage use
where suitable and to discourage use where unsuitable.
___
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 Dec 2, 2017, at 2:13 PM, Matthew Johnson  wrote:
>> For all those reasons, we really do need something like AnyObject dispatch 
>> if we care about working with dynamically typed languages.  The design I’m 
>> suggesting carefully cordons this off into its own struct type, so it 
>> doesn’t infect the rest of the type system, and is non-invasive in the 
>> compiler.
> 
> I am quite familiar with dynamic languages and agree that this is necessary 
> if we are going to fully open up access to these languages from Swift.

Ok, then it appears you agree that something like anyobject dispatch is 
necessary for effective dynamic language interop.

>>> I strongly urge you to reconsider the decision of that dynamic members must 
>>> be made available with no indication at usage sites.  An indication of 
>>> dynamic lookup at usage sites aligns very well (IMO) with the rest of Swift 
>>> (AnyObject lookup aside) by calling attention to code that requires extra 
>>> care to get right.
>> 
>> I don’t understand this.  The proposal is fully type safe, and this approach 
>> is completely precedented by AnyObject.  Swift’s type system supports many 
>> ways to express fallibility, and keeping those decisions orthogonal to this 
>> proposal is the right thing to do, because it allows the author of the type 
>> to decide what model makes sense for them.
> 
> Allowing the author of the type to choose whether the mechanism is hidden or 
> visible is exactly what I don’t want to allow.  I think you have the right 
> design regarding types and semantics - the author chooses.  But I don’t want 
> these calls to look like ordinary member lookup when I’m reading code.  
> 
> They inherently have a much greater chance of failure than ordinary member 
> lookup.  Further, authors are likely to choose immediate traps or nil IUO as 
> failure modes as forcing users to deal with Optional on every call is likely 
> to be untenable.  I believe this behavior should be represented by some kind 
> of syntax at the usage site.  I don’t believe it is an undue burden.  It 
> would make the dynamic lookup semantic clear to all readers and would help to 
> discourage abuse.

I believe that adding explicit syntax would be counterproductive to your goals, 
and would not make dynamic lookup syntax more clear.  I assume that you would 
also want the same thing for DynamicCallable too, and operator overloads, 
subscripts, and every other operation you perform on these values, since they 
all have the exact same behavior.

If we required some syntax even as minimal as “foo.^bar” and "baz^(42)”, that 
change would turn this (which uses runtime failing or IUO return values like 
AnyObject):

let np = Python.import("numpy")
let x = np.array([6, 7, 8])
let y =  np.arange(24).reshape(2, 3, 4)

let a = np.ones(3, dtype: np.int32)
let b = np.linspace(0, pi, 3)
let c = a+b
let d = np.exp(c)
print(d)

into:

let np = Python.import("numpy")
let b = np^.array^([6, 7, 8])
let y =  np^.arange^(24)^.reshape^(2, 3, 4)

let a = np^.ones^(3, dtype: np^.int32)
let b = np^.linspace^(0, pi, 3)
let c = a+^b
let d = np^.exp^(c)

This does not improve clarity of code, it merely serves to obfuscate logic.  It 
is immediately apparent from the APIs being used, the API style, and the static 
types (in Xcode or through static declarations) that this is all Python stuff.  
When you start mixing in use of native Swift types like dictionaries (something 
we want to encourage because they are typed!) you end up with an inconsistent 
mismash where people would just try adding syntax or applying fixits 
continuously until the code builds.

Beyond that, it is counterproductive to your goals, because it means that 
people are far less likely to use to use optional returns.  Doing so (which 
produces a safer result) would cause a double tax in syntax, and would be a 
confusing jumble.  I can’t bring myself to do the whole example above, one line 
- just converting member lookup syntax but not callable syntax - would end up:

let y =  np^.arange?^(24)^.reshape^?(2, 3, 4)

If you made DynamicCallable also return optional it would be:

let y =  np^.arange?^(24)?^.reshape^?(2, 3, 4)!

or something.  This is such madness that no one would do that.


>> Swift already has a dynamic member lookup feature, "AnyObject dispatch" 
>> which does not use additional punctuation, so this would break precedent.
> I would prefer if dynamic lookup were visible with AnyObject as well.  For 
> that reason I don’t believe it makes a good precedent to follow.  In fact, I 
> would prefer to see us go the other direction and perhaps even consider 
> revising dynamic lookup syntax for AnyObject in the future.

This is definitely not going to happen.  The change Doug mentioned is to have 
AnyObject lookup return optional instead of IUO, 

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

[Greg Parker via swift-evolution]

> On Dec 2, 2017, at 1:09 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon  > wrote:
>> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> That said, I am not sure that this proposal should give any pretense of 
>> being suitable for cryptographic use. On implementation, the code will not 
>> have been audited for that purpose, although the author very rightly 
>> attempts to use the "best" possible sources of entropy available for each 
>> platform. Perhaps explicitly _not_ supporting cryptographic operations is 
>> the more Swifty way to go (in the sense that, where possible, Swift API 
>> design aims to help users avoid footguns).
> 
> People will use it for crypto whether we want them to or not.
> 
> People are going to do all sorts of unanticipated things, sure. But this 
> doesn't mean that we shouldn't consider how we may best encourage users to 
> avoid _unintentional_ common pitfalls.
> 
> There are options to explore here. Consider, for example--and I'm not 
> suggesting that we be this verbose, but it is illustrative of the trade-offs 
> which are possible to keep in mind--if certain methods were very clear that 
> the result is *pseudorandom* and potentially *insecure*: 
> `(0..<9).insecurePseudorandomElement`. Clearly, fewer people would use this 
> method for crypto.

But what *should* they use instead of our API? The OS-provided CSPRNG is almost 
certainly going to be the most secure thing available in the absence of 
specialized hardware. We should not deliberately scare users away from our API 
if there is nothing better on offer.


-- 
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] [RFC] Associated type inference

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Dec 2, 2017, at 4:40 PM, Douglas Gregor  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Dec 2, 2017, at 1:37 PM, Matthew Johnson  wrote:
>> 
>> 
>>> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> Associated type inference, which is the process by which the Swift compiler 
>>> attempts to infer typealiases to satisfy associated-type requirements based 
>>> on other requirements, has caused both implementation problems and user 
>>> confusion for a long time. Some of you might remember a previous (failed) 
>>> attempt to remove this feature from the Swift language, in SE-0108 “Remove 
>>> associated type inference”. 
>>> 
>>> I’m not sure we can remove this feature outright (i.e., the concerns that 
>>> sank that proposal are still absolutely valid), because it is so very 
>>> convenient and a lot of user code likely depends on it in some form or 
>>> other. So, here I’d like to describe the uses of the feature, its current 
>>> (very problematic) implementation approach, and a half-baked proposal to 
>>> narrow the scope of associated type inference to something that I think is 
>>> more tractable. I need help with the design of this feature, because I feel 
>>> like it’s going to be a delicate balance between implementability and 
>>> expressiveness.
>>> 
>>> A Motivating Example
>>> As a motivating example, let’s consider a “minimal” random access 
>>> collection:
>>> 
>>> struct MyCollection {
>>> var contents: [T]
>>> }
>>> 
>>> extension MyCollection: RandomAccessCollection {
>>> var startIndex: Int { return contents.startIndex }
>>> var endIndex: Int { return contents.endIndex }
>>> subscript(index: Int) -> T { return contents[index] }
>>> }
>>> 
>>> This is actually pretty awesome: by providing just two properties and a 
>>> subscript, we get the full breadth of the random access collection API! 
>>> This is relying heavily on associated type inference (for associated type 
>>> requirements) and default implementations specified on protocol extensions. 
>>> Without associated type inference, we would have had to write:
>>> 
>>> 
>>> extension MyCollection: RandomAccessCollection {
>>> typealias Element = T
>>> typealias Index = Int
>>> typealias Indices = CountableRange
>>> typealias Iterator = IndexingIterator
>>> typealias SubSequence = RandomAccessSlice
>>> 
>>> var startIndex: Int { return contents.startIndex }
>>> var endIndex: Int { return contents.endIndex }
>>> subscript(index: Int) -> T { return contents[index] }
>>> }
>>> 
>>> where the bolded typealiases are currently inferred. It was worse back when 
>>> we reviewed SE-0108, because IIRC there were a few underscored associated 
>>> types (e.g., _Element) that have since been removed. Still, that’s a bit of 
>>> additional work to define a “minimal” collection, and requires quite a bit 
>>> more understanding: how do I know to choose IndexingIterator, and 
>>> CountableRange, and RandomAccessSlice?
>>> 
>>> The issue would get worse with, e.g., SE-0174 “Change filter to return an 
>>> associated type”, which adds an associated type Filtered that almost nobody 
>>> will ever customize, and isn’t really fundamental to the way collections 
>>> work. Adding Filtered to the standard library would be a source-breaking 
>>> change, because users would have to write a typealias giving it its default.
>>> 
>>> Associated Type Defaults
>>> One of the ways in which we avoid having to specify typealiases is to use 
>>> associated type defaults. For example, the standard library contains 
>>> associated type defaults for Indices, Iterator, and SubSequence. Let’s 
>>> focus on Indices:
>>> 
>>> protocol Collection : Sequence {
>>>   associatedtype Indices = DefaultIndices
>>>   // ...
>>> }
>>> 
>>> protocol BidirectionalCollection : Collection {
>>>   associatedtype Indices = DefaultBidirectionalIndices
>>>   // ...
>>> }
>>> 
>>> protocol RandomAccessCollection : BidirectionalCollection {
>>>   associatedtype Indices = DefaultRandomAccessIndices
>>>   // ...
>>> }
>>> 
>>> The basic idea here is that different protocols in the hierarchy provide 
>>> different defaults, and you presumably want the default from the most 
>>> specific protocol. If I define a type and make it conform to 
>>> BidirectionalCollection, I’d expect to get 
>>> DefaultBidirectionalIndices for Indices. If a define a type and make 
>>> it conform to RandomAccessIterator, I’d expect to get 
>>> DefaultRandomAccessIndices.
>>> 
>>> (Aside: DefaultRandomAccessIndices and DefaultBidirectionalIndices got 
>>> collapsed into DefaultIndices now that we have conditional conformances for 
>>> the standard library, but the issues I’m describing remain).
>>> 
>>> Associated type defaults seem like a reasonable feature that fits well 
>>> 

Re: [swift-evolution] [RFC] Associated type inference

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Dec 2, 2017, at 1:37 PM, Matthew Johnson  wrote:
> 
> 
>> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> Associated type inference, which is the process by which the Swift compiler 
>> attempts to infer typealiases to satisfy associated-type requirements based 
>> on other requirements, has caused both implementation problems and user 
>> confusion for a long time. Some of you might remember a previous (failed) 
>> attempt to remove this feature from the Swift language, in SE-0108 “Remove 
>> associated type inference”. 
>> 
>> I’m not sure we can remove this feature outright (i.e., the concerns that 
>> sank that proposal are still absolutely valid), because it is so very 
>> convenient and a lot of user code likely depends on it in some form or 
>> other. So, here I’d like to describe the uses of the feature, its current 
>> (very problematic) implementation approach, and a half-baked proposal to 
>> narrow the scope of associated type inference to something that I think is 
>> more tractable. I need help with the design of this feature, because I feel 
>> like it’s going to be a delicate balance between implementability and 
>> expressiveness.
>> 
>> A Motivating Example
>> As a motivating example, let’s consider a “minimal” random access collection:
>> 
>> struct MyCollection {
>> var contents: [T]
>> }
>> 
>> extension MyCollection: RandomAccessCollection {
>> var startIndex: Int { return contents.startIndex }
>> var endIndex: Int { return contents.endIndex }
>> subscript(index: Int) -> T { return contents[index] }
>> }
>> 
>> This is actually pretty awesome: by providing just two properties and a 
>> subscript, we get the full breadth of the random access collection API! This 
>> is relying heavily on associated type inference (for associated type 
>> requirements) and default implementations specified on protocol extensions. 
>> Without associated type inference, we would have had to write:
>> 
>> 
>> extension MyCollection: RandomAccessCollection {
>> typealias Element = T
>> typealias Index = Int
>> typealias Indices = CountableRange
>> typealias Iterator = IndexingIterator
>> typealias SubSequence = RandomAccessSlice
>> 
>> var startIndex: Int { return contents.startIndex }
>> var endIndex: Int { return contents.endIndex }
>> subscript(index: Int) -> T { return contents[index] }
>> }
>> 
>> where the bolded typealiases are currently inferred. It was worse back when 
>> we reviewed SE-0108, because IIRC there were a few underscored associated 
>> types (e.g., _Element) that have since been removed. Still, that’s a bit of 
>> additional work to define a “minimal” collection, and requires quite a bit 
>> more understanding: how do I know to choose IndexingIterator, and 
>> CountableRange, and RandomAccessSlice?
>> 
>> The issue would get worse with, e.g., SE-0174 “Change filter to return an 
>> associated type”, which adds an associated type Filtered that almost nobody 
>> will ever customize, and isn’t really fundamental to the way collections 
>> work. Adding Filtered to the standard library would be a source-breaking 
>> change, because users would have to write a typealias giving it its default.
>> 
>> Associated Type Defaults
>> One of the ways in which we avoid having to specify typealiases is to use 
>> associated type defaults. For example, the standard library contains 
>> associated type defaults for Indices, Iterator, and SubSequence. Let’s focus 
>> on Indices:
>> 
>> protocol Collection : Sequence {
>>   associatedtype Indices = DefaultIndices
>>   // ...
>> }
>> 
>> protocol BidirectionalCollection : Collection {
>>   associatedtype Indices = DefaultBidirectionalIndices
>>   // ...
>> }
>> 
>> protocol RandomAccessCollection : BidirectionalCollection {
>>   associatedtype Indices = DefaultRandomAccessIndices
>>   // ...
>> }
>> 
>> The basic idea here is that different protocols in the hierarchy provide 
>> different defaults, and you presumably want the default from the most 
>> specific protocol. If I define a type and make it conform to 
>> BidirectionalCollection, I’d expect to get DefaultBidirectionalIndices 
>> for Indices. If a define a type and make it conform to RandomAccessIterator, 
>> I’d expect to get DefaultRandomAccessIndices.
>> 
>> (Aside: DefaultRandomAccessIndices and DefaultBidirectionalIndices got 
>> collapsed into DefaultIndices now that we have conditional conformances for 
>> the standard library, but the issues I’m describing remain).
>> 
>> Associated type defaults seem like a reasonable feature that fits well 
>> enough into the design. However, it’s not the only thing in place with our 
>> MyCollection example, for which Indices was inferred to CountableRange. 
>> How’s that happen?
>> 
>> Associated Type Inference
>> Associated 

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

[Matthew Johnson via swift-evolution]

> On Dec 2, 2017, at 2:44 PM, Chris Lattner  wrote:
> 
> On Dec 1, 2017, at 5:50 PM, Matthew Johnson  > wrote:
 This design introduces a significant hole in the type system which is 
 contrary to the spirit of Swift.
>>> 
>>> There is no “hole” in the type system.  The proposal is fully type safe. 
>>> 
>>> Further, the addition is absolutely in the spirit of Swift, because it is 
>>> directly analogous to an existing feature: AnyObject lookup.  The 
>>> difference between it and AnyObject lookup is that AnyObject lookup is:
>>> 
>>> a) specific to Objective-C interop
>>> b) type unsafe
>>> c) massively invasive on the rest of the compiler.
>>> 
>>> We’ve made many attempts to narrow the scope of AnyObject lookup, but it is 
>>> difficult to do so given backwards compatibility constraints and the 
>>> limited nature of Objective-C metadata.
>> 
>> I may have spoken incorrectly but I do still believe it is contrary to what 
>> I (and apparently many others) feel is the spirit of Swift.  
>> 
>> As I understand it, AnyObject lookup was a necessity during the historical 
>> development of Swift.  The attempts to narrow its scope have merit 
>> regardless of how far they can go.  They indicate that perhaps it is a 
>> feature we would remove if that were possible.  I would love to see that 
>> happen someday (although I know it is unlikely), or at least see it be made 
>> explicit at the call site.  I suspect if this feature did not exist and it 
>> was proposed today it would be met with at least as much resistance as your 
>> proposals have.
> 
> This isn’t the way I see it.  You’re right that we want to reduce AnyObject 
> dispatch wherever possible: types are good after all.  Swift on Linux doesn’t 
> even have AnyObject dispatch, so you can tell that it is a means to an end, 
> not a feature that we think is great for Swift on its own merits.

It’s a means to an end and the need for that end is growing smaller over time.

> 
> What is that end?  It is interoperability with truly dynamic values, which do 
> occur in Objective-C, where pervasive casting would harm code clarity and 
> usability.  The desire to fix AnyObject you are seeing are related to two 
> different issues: 1) The design of AnyObject dispatch itself is problematic 
> in some ways, and 2) many values in ObjC APIs were typed as id simply because 
> there was no way to describe a more specific type given Objective-C’s 
> original type system (which has been improved).  However, given the presence 
> of actually polymorphic values being used by some APIs, I don’t imagine it 
> going away entirely.

Which is a reason to consider making this mechanism more visible in the syntax.

> 
> 
> In the case of other dynamic languages, the situation is even more severe.  
> Some dynamic languages have progressive type systems available, but not all 
> do.  Those which do have to deal with the fact that the base languages were 
> not designed for typing systems, which is far more severe a problem than 
> Objective-C’s situation.  
> 
> If you haven’t already, I encourage you to read the mypy docs 
> (http://mypy.readthedocs.io/en/stable/index.html 
> ) to understand how the type 
> system they’re trying to build on top of Python works.  They have to contend 
> with things like:
> 
> - the single array subscript operator taking both scalars and ranges, and 
> returning different type results depending on their input (Python has no 
> overloading)
> - pervasive use of duck typing, e.g. int is duck type compatible with float 
> and complex (duck typing is for many non-primitive types as well)
> - pervasive use of variance
> - APIs creep to “just work” when passed all sorts of weird values, meaning 
> that their API contract is extremely loose.
> - Python supports *dynamically computed base classes* and lots of other crazy 
> things.
> - and more..
> 
> Mypy also only supports a subset of Python - it doesn’t support properties 
> with setters as one example, and its generic and class system is only 
> partially implemented.  The only way to use it in practice is to use their 
> ability to silence warnings, it is not an acceptable basis for a sound type 
> system that we could depend on in Swift.
> 
> 
> For all those reasons, we really do need something like AnyObject dispatch if 
> we care about working with dynamically typed languages.  The design I’m 
> suggesting carefully cordons this off into its own struct type, so it doesn’t 
> infect the rest of the type system, and is non-invasive in the compiler.

I am quite familiar with dynamic languages and agree that this is necessary if 
we are going to fully open up access to these languages from Swift.

> 
> 
 It doesn’t just make dynamic language interop easy, it also changes the 
 semantics of any type which conforms to DynamicMemberLookupProtocol.  That 
 

Re: [swift-evolution] [RFC] Associated type inference

[Matthew Johnson via swift-evolution]

> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> Associated type inference, which is the process by which the Swift compiler 
> attempts to infer typealiases to satisfy associated-type requirements based 
> on other requirements, has caused both implementation problems and user 
> confusion for a long time. Some of you might remember a previous (failed) 
> attempt to remove this feature from the Swift language, in SE-0108 “Remove 
> associated type inference”. 
> 
>  
> 
> I’m not sure we can remove this feature outright (i.e., the concerns that 
> sank that proposal are still absolutely valid), because it is so very 
> convenient and a lot of user code likely depends on it in some form or other. 
> So, here I’d like to describe the uses of the feature, its current (very 
> problematic) implementation approach, and a half-baked proposal to narrow the 
> scope of associated type inference to something that I think is more 
> tractable. I need help with the design of this feature, because I feel like 
> it’s going to be a delicate balance between implementability and 
> expressiveness.
> 
> A Motivating Example
> As a motivating example, let’s consider a “minimal” random access collection:
> 
> struct MyCollection {
> var contents: [T]
> }
> 
> extension MyCollection: RandomAccessCollection {
> var startIndex: Int { return contents.startIndex }
> var endIndex: Int { return contents.endIndex }
> subscript(index: Int) -> T { return contents[index] }
> }
> 
> This is actually pretty awesome: by providing just two properties and a 
> subscript, we get the full breadth of the random access collection API! This 
> is relying heavily on associated type inference (for associated type 
> requirements) and default implementations specified on protocol extensions. 
> Without associated type inference, we would have had to write:
> 
> 
> extension MyCollection: RandomAccessCollection {
> typealias Element = T
> typealias Index = Int
> typealias Indices = CountableRange
> typealias Iterator = IndexingIterator
> typealias SubSequence = RandomAccessSlice
> 
> var startIndex: Int { return contents.startIndex }
> var endIndex: Int { return contents.endIndex }
> subscript(index: Int) -> T { return contents[index] }
> }
> 
> where the bolded typealiases are currently inferred. It was worse back when 
> we reviewed SE-0108, because IIRC there were a few underscored associated 
> types (e.g., _Element) that have since been removed. Still, that’s a bit of 
> additional work to define a “minimal” collection, and requires quite a bit 
> more understanding: how do I know to choose IndexingIterator, and 
> CountableRange, and RandomAccessSlice?
> 
> The issue would get worse with, e.g., SE-0174 “Change filter to return an 
> associated type” 
> ,
>  which adds an associated type Filtered that almost nobody will ever 
> customize, and isn’t really fundamental to the way collections work. Adding 
> Filtered to the standard library would be a source-breaking change, because 
> users would have to write a typealias giving it its default.
> 
> Associated Type Defaults
> One of the ways in which we avoid having to specify typealiases is to use 
> associated type defaults. For example, the standard library contains 
> associated type defaults for Indices, Iterator, and SubSequence. Let’s focus 
> on Indices:
> 
> protocol Collection : Sequence {
>   associatedtype Indices = DefaultIndices
>   // ...
> }
> 
> protocol BidirectionalCollection : Collection {
>   associatedtype Indices = DefaultBidirectionalIndices
>   // ...
> }
> 
> protocol RandomAccessCollection : BidirectionalCollection {
>   associatedtype Indices = DefaultRandomAccessIndices
>   // ...
> }
> 
> The basic idea here is that different protocols in the hierarchy provide 
> different defaults, and you presumably want the default from the most 
> specific protocol. If I define a type and make it conform to 
> BidirectionalCollection, I’d expect to get DefaultBidirectionalIndices 
> for Indices. If a define a type and make it conform to RandomAccessIterator, 
> I’d expect to get DefaultRandomAccessIndices.
> 
> (Aside: DefaultRandomAccessIndices and DefaultBidirectionalIndices got 
> collapsed into DefaultIndices now that we have conditional conformances for 
> the standard library , but the 
> issues I’m describing remain).
> 
> Associated type defaults seem like a reasonable feature that fits well enough 
> into the design. However, it’s not the only thing in place with our 
> MyCollection example, for which Indices was inferred to CountableRange. How’s 
> that happen?
> 

Re: [swift-evolution] [RFC] Associated type inference

[Xiaodi Wu via swift-evolution]

On Sat, Dec 2, 2017 at 2:30 PM, Howard Lovatt via swift-evolution <
swift-evolution@swift.org> wrote:

> Definitely in favour of doing something, I always define the associated
> types since I have had so much trouble with the inference.
>
> Personally I would prefer just 1 and 2 and forget 3. I know this would
> break a lot of code, but I think we should do that because it is the lesser
> of the evils.
>

As Doug wrote, an approach that's essentially that was reviewed and
rejected in SE-0108. We already know that it's not acceptable to a great
proportion of the community.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon 
wrote:

> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> That said, I am not sure that this proposal should give any pretense of
> being suitable for cryptographic use. On implementation, the code will not
> have been audited for that purpose, although the author very rightly
> attempts to use the "best" possible sources of entropy available for each
> platform. Perhaps explicitly _not_ supporting cryptographic operations is
> the more Swifty way to go (in the sense that, where possible, Swift API
> design aims to help users avoid footguns).
>
>
> People will use it for crypto whether we want them to or not.
>

People are going to do all sorts of unanticipated things, sure. But this
doesn't mean that we shouldn't consider how we may best encourage users to
avoid _unintentional_ common pitfalls.

There are options to explore here. Consider, for example--and I'm not
suggesting that we be this verbose, but it is illustrative of the
trade-offs which are possible to keep in mind--if certain methods were very
clear that the result is *pseudorandom* and potentially *insecure*:
`(0..<9).insecurePseudorandomElement`. Clearly, fewer people would use this
method for crypto.

None of the proposals involve actually writing cryptographic primitives,
> just calling out to well-known functions like `arc4random()` or reading
> from special devices like `/dev/urandom`. I would hope that Apple's
> security team can spare the time to review the security-critical parts and
> sign off on them, and I'd be perfectly happy to see this proposal be
> approved but the final merge into the language be deferred until they've
> taken a look at it.
>
___
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 Dec 1, 2017, at 5:50 PM, Matthew Johnson  wrote:
>>> This design introduces a significant hole in the type system which is 
>>> contrary to the spirit of Swift.
>> 
>> There is no “hole” in the type system.  The proposal is fully type safe. 
>> 
>> Further, the addition is absolutely in the spirit of Swift, because it is 
>> directly analogous to an existing feature: AnyObject lookup.  The difference 
>> between it and AnyObject lookup is that AnyObject lookup is:
>> 
>> a) specific to Objective-C interop
>> b) type unsafe
>> c) massively invasive on the rest of the compiler.
>> 
>> We’ve made many attempts to narrow the scope of AnyObject lookup, but it is 
>> difficult to do so given backwards compatibility constraints and the limited 
>> nature of Objective-C metadata.
> 
> I may have spoken incorrectly but I do still believe it is contrary to what I 
> (and apparently many others) feel is the spirit of Swift.  
> 
> As I understand it, AnyObject lookup was a necessity during the historical 
> development of Swift.  The attempts to narrow its scope have merit regardless 
> of how far they can go.  They indicate that perhaps it is a feature we would 
> remove if that were possible.  I would love to see that happen someday 
> (although I know it is unlikely), or at least see it be made explicit at the 
> call site.  I suspect if this feature did not exist and it was proposed today 
> it would be met with at least as much resistance as your proposals have.

This isn’t the way I see it.  You’re right that we want to reduce AnyObject 
dispatch wherever possible: types are good after all.  Swift on Linux doesn’t 
even have AnyObject dispatch, so you can tell that it is a means to an end, not 
a feature that we think is great for Swift on its own merits.

What is that end?  It is interoperability with truly dynamic values, which do 
occur in Objective-C, where pervasive casting would harm code clarity and 
usability.  The desire to fix AnyObject you are seeing are related to two 
different issues: 1) The design of AnyObject dispatch itself is problematic in 
some ways, and 2) many values in ObjC APIs were typed as id simply because 
there was no way to describe a more specific type given Objective-C’s original 
type system (which has been improved).  However, given the presence of actually 
polymorphic values being used by some APIs, I don’t imagine it going away 
entirely.


In the case of other dynamic languages, the situation is even more severe.  
Some dynamic languages have progressive type systems available, but not all do. 
 Those which do have to deal with the fact that the base languages were not 
designed for typing systems, which is far more severe a problem than 
Objective-C’s situation.  

If you haven’t already, I encourage you to read the mypy docs 
(http://mypy.readthedocs.io/en/stable/index.html 
) to understand how the type 
system they’re trying to build on top of Python works.  They have to contend 
with things like:

- the single array subscript operator taking both scalars and ranges, and 
returning different type results depending on their input (Python has no 
overloading)
- pervasive use of duck typing, e.g. int is duck type compatible with float and 
complex (duck typing is for many non-primitive types as well)
- pervasive use of variance
- APIs creep to “just work” when passed all sorts of weird values, meaning that 
their API contract is extremely loose.
- Python supports *dynamically computed base classes* and lots of other crazy 
things.
- and more..

Mypy also only supports a subset of Python - it doesn’t support properties with 
setters as one example, and its generic and class system is only partially 
implemented.  The only way to use it in practice is to use their ability to 
silence warnings, it is not an acceptable basis for a sound type system that we 
could depend on in Swift.


For all those reasons, we really do need something like AnyObject dispatch if 
we care about working with dynamically typed languages.  The design I’m 
suggesting carefully cordons this off into its own struct type, so it doesn’t 
infect the rest of the type system, and is non-invasive in the compiler.


>>> It doesn’t just make dynamic language interop easy, it also changes the 
>>> semantics of any type which conforms to DynamicMemberLookupProtocol.  That 
>>> is not something that is locally visible when looking at a piece of code.  
>>> Worse, it does so in a way that trivial mistakes such as a typo can turn 
>>> into runtime errors.  Worst of all, as Doug points out it is possible to 
>>> use retroactive conformance to change the semantics of vast quantities of 
>>> widely used types in one fell swoop.
>> 
>> This is a feature, like many others, which can be misused.  This has not 
>> been the metric we have used to judge what should go into Swift.  I can 
>> elaborate if my response to Doug wasn’t clear.
> 
> The 

Re: [swift-evolution] [RFC] Associated type inference

[Howard Lovatt via swift-evolution]

Definitely in favour of doing something, I always define the associated types 
since I have had so much trouble with the inference. 

Personally I would prefer just 1 and 2 and forget 3. I know this would break a 
lot of code, but I think we should do that because it is the lesser of the 
evils. 

-- Howard. 

> On 1 Dec 2017, at 11:20 pm, Johannes Weiß via swift-evolution 
>  wrote:
> 
> Hi Douglas,
> 
> First of all, thanks very much for looking into this seemingly dark corner of 
> the compiler. This caused us a lot of trouble already.
> 
> Comments inline.
> 
>> On 1 Dec 2017, at 12:28 am, Douglas Gregor via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> Associated type inference, which is the process by which the Swift compiler 
>> attempts to infer typealiases to satisfy associated-type requirements based 
>> on other requirements, has caused both implementation problems and user 
>> confusion for a long time. Some of you might remember a previous (failed) 
>> attempt to remove this feature from the Swift language, in SE-0108 “Remove 
>> associated type inference”. 
>> 
>> I’m not sure we can remove this feature outright (i.e., the concerns that 
>> sank that proposal are still absolutely valid), because it is so very 
>> convenient and a lot of user code likely depends on it in some form or 
>> other. So, here I’d like to describe the uses of the feature, its current 
>> (very problematic) implementation approach, and a half-baked proposal to 
>> narrow the scope of associated type inference to something that I think is 
>> more tractable. I need help with the design of this feature, because I feel 
>> like it’s going to be a delicate balance between implementability and 
>> expressiveness.
>> 
>> A Motivating Example
>> As a motivating example, let’s consider a “minimal” random access collection:
>> 
>> struct MyCollection {
>>  var contents: [T]
>> }
>> 
>> extension MyCollection: RandomAccessCollection {
>>  var startIndex: Int { return contents.startIndex }
>>  var endIndex: Int { return contents.endIndex }
>>  subscript(index: Int) -> T { return contents[index] }
>> }
>> 
>> This is actually pretty awesome: by providing just two properties and a 
>> subscript, we get the full breadth of the random access collection API! This 
>> is relying heavily on associated type inference (for associated type 
>> requirements) and default implementations specified on protocol extensions. 
>> Without associated type inference, we would have had to write:
>> 
>> 
>> extension MyCollection: RandomAccessCollection {
>>  typealias Element = T
>>  typealias Index = Int
>>  typealias Indices = CountableRange
>>  typealias Iterator = IndexingIterator
>>  typealias SubSequence = RandomAccessSlice
>> 
>>  var startIndex: Int { return contents.startIndex }
>>  var endIndex: Int { return contents.endIndex }
>>  subscript(index: Int) -> T { return contents[index] }
>> }
>> 
>> where the bolded typealiases are currently inferred. It was worse back when 
>> we reviewed SE-0108, because IIRC there were a few underscored associated 
>> types (e.g., _Element) that have since been removed. Still, that’s a bit of 
>> additional work to define a “minimal” collection, and requires quite a bit 
>> more understanding: how do I know to choose IndexingIterator, and 
>> CountableRange, and RandomAccessSlice?
>> 
>> The issue would get worse with, e.g., SE-0174 “Change filter to return an 
>> associated type”, which adds an associated type Filtered that almost nobody 
>> will ever customize, and isn’t really fundamental to the way collections 
>> work. Adding Filtered to the standard library would be a source-breaking 
>> change, because users would have to write a typealias giving it its default.
>> 
>> Associated Type Defaults
>> One of the ways in which we avoid having to specify typealiases is to use 
>> associated type defaults. For example, the standard library contains 
>> associated type defaults for Indices, Iterator, and SubSequence. Let’s focus 
>> on Indices:
>> 
>> protocol Collection : Sequence {
>> associatedtype Indices = DefaultIndices
>> // ...
>> }
>> 
>> protocol BidirectionalCollection : Collection {
>> associatedtype Indices = DefaultBidirectionalIndices
>> // ...
>> }
>> 
>> protocol RandomAccessCollection : BidirectionalCollection {
>> associatedtype Indices = DefaultRandomAccessIndices
>> // ...
>> }
>> 
>> The basic idea here is that different protocols in the hierarchy provide 
>> different defaults, and you presumably want the default from the most 
>> specific protocol. If I define a type and make it conform to 
>> BidirectionalCollection, I’d expect to get DefaultBidirectionalIndices 
>> for Indices. If a define a type and make it conform to RandomAccessIterator, 
>> I’d expect to get DefaultRandomAccessIndices.
>> 
>> (Aside: DefaultRandomAccessIndices and DefaultBidirectionalIndices got 
>> collapsed 

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

[Mike Kluev via swift-evolution]

Correct me if I’m wrong, but to me it looks like the main objectives to this 
proposal are cleared once we make it either a DynamicObject (vs a dynamic 
protocol) or we restrict this protocol adoptions to be only possible from 
within the main body of types, so in no way it will be possible to 
retrospectively extend, say, NSObject to conform to this protocol. Cool.

About the only bit missing is autocomplete and other mentioned things like goto 
definition, indexing, etc... IMHO these are not that important... but ok, 
assuming they are... we have a precedent of image literals to effectively 
“autocomplete” UIImage(named: “string”), perhaps we can have a similarity 
machinery that can autocomplete the relevant python method names and check for 
the typos. all during compile time.

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

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Matthew Johnson via swift-evolution]

This thread received very light, but positive feedback.  I would really like to 
see this feature added and am willing to draft and official proposal but am not 
able to implement it.  If anyone is interested in collaborating just let me 
know.


> On Nov 24, 2017, at 5:03 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> One of the most frequent frustrations I encounter when writing generic code 
> in Swift is the requirement that supertype constraints be concrete.  When I 
> mentioned this on Twitter 
> (https://twitter.com/anandabits/status/929958479598534656 
> ) Doug Gregor 
> mentioned that this feature is smaller and mostly straightforward to design 
> and implement (https://twitter.com/dgregor79/status/929975472779288576 
> ).
> 
> I currently have a PR open to add the high-level description of this feature 
> found below to the generics manifesto 
> (https://github.com/apple/swift/pull/13012 
> ):
> 
> Currently, supertype constraints may only be specified using a concrete class 
> or protocol type.  This prevents us from abstracting over the supertype.
> 
> ```swift
> protocol P {
>   associatedtype Base
>   associatedtype Derived: Base
> }
> ```
> 
> In the above example `Base` may be any type.  `Derived` may be the same as 
> `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
> supported by Swift should be supported in this context including, but not 
> limited to, classes and subclasses, existentials and conforming concrete 
> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
> `((Derived) -> Void)`, etc.
> 
> Generalized supertype constraints would be accepted in all syntactic 
> locations where generic constraints are accepted.
> 
> I would like to see generalized supertype constraints make it into Swift 5 if 
> possible.  I am not an implementer so I will not be able to bring a proposal 
> forward alone but am interested in collaborating with anyone interested in 
> working on implementation.
> 
> I am also interested in hearing general feedback on this feature from the 
> community at large.  Have you also found this limitation frustrating?  In 
> what contexts?  Does anyone have reservations about introducing this 
> capability?  If so, what are they?
> 
> Matthew
> 
> ___
> 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

[Tino Heth via swift-evolution]

>> I’ve addressed both of these issues above. The approach I am proposing 
>> requires no language or compiler support, works with existing Swift tooling, 
>> fits with an existing notion in the language (AnyObject), and can be 
>> implemented via a Python script.
> 
> I’m very confused, are you suggesting a preprocessor, or something actually 
> integrated with the compiler?  The goal here is to provide something with 
> acceptable usability that encourages exploration and playing around.

I can’t answer the question (although I have a theory ;-), but imho 
"exploration and playing around“ benefits quite a lot from proper code 
completion.
So whatever solution is chosen, it probably will require library specific 
glue-code for the best user experience (assuming that we actually need a 
solution — I personally have no need for Python interop, and I don’t know how 
big general interest is).

The two proposals might help writing that glue code, but I’m not sure they are 
that important when a generator is used to create the bindings.___
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]

HI Doug,

Your approach can definitely work, but before responding with a tradeoff 
analysis, I’d like to make sure that I understand what you’re suggesting 
specifically.

> On Dec 1, 2017, at 10:39 AM, Douglas Gregor  wrote:
>>  It also doesn’t provide the great tooling experience that you’re seeking, 
>> given that code completion would show everything in the Python universe, 
>> which is not helpful.
> 
> It’s better for code completion to provide too much than to provide nothing 
> at all. If code completion provides too much, typing a small number of 
> characters will reduce the completion set down to something manageable quite 
> fast.

Yes, I understand your goal.

> DynamicMemberLookup doesn’t gave any of those, because “add_trick” is just a 
> string that looks like an identifier. Only the Python runtime can resolve.

Agreed.

>> A preprocessing step prevents users from playfully importing random Python 
>> modules into the Swift repl and playgrounds.
> 
> *At worst*, you invoke the tool from the command line to build the Swift 
> module that corresponds to a given Python module.
> 
>   py2swift 
> 
> We could absolutely introduce tooling hooks to make the compiler initiate 
> that step.

This would have to be integrated into the swift compiler to provide a usable 
experience IMO, because otherwise it won’t work with Playgrounds.

>>  It also seems worse for implementors (who will get a stream of new bugs 
>> about compiler scalability).
> 
> To my knowledge, AnyObject lookup has not been a serious source of 
> performance problems for the compiler. The global lookup table it requires 
> was annoying to implement, but it’s just a symbol table.

Right, AnyObject lookup itself is not a problem, because significant 
engineering effort has been put in place to build a module cache that can be 
efficiently queried.  I thought you were suggesting that we do a preprocessing 
step to smoosh together all of the “interesting” python APIs into a single huge 
extension on PyVal which would then be literally parsed and that overload 
resolution would resolve against.  This approach would perform very differently 
than AnyObject lookup does for ObjC.

>>> Python plugins for IDEs (e.g., for Atom) provide code completion, goto 
>>> definition, and other related features. None of the Swift tooling will work 
>>> if Swift’s interoperability with Python is entirely based on 
>>> DynamicMemberLookupProtocol.
>> 
>> I don’t understand your rationale here.  I think you agree that we need to 
>> support the fully dynamic case (which is what I’m proposing).  That said, 
>> this step does not preclude introducing importer magic (either through 
>> compiler hackery or a theoretical "type providers” style of feature).  Doing 
>> so would provide the functionality you’re describing.
> 
> I don’t agree that we need language support for the fully-dynamic case. There 
> has to be a way to handle the fully-dynamic case, but it can be string-based 
> APIs vended by an Python interoperability library.
> 
> I believe that the majority of property and method accesses in Python 
> programs will be resolved to a definition in the current model or an imported 
> module, i.e., a definition that is visible to the compiler at compile-time. 
> There are exceptional cases involving programmatically creating properties 
> from JSON, a database, etc., but while prominent I suspect they account for a 
> relatively small fraction of use sites. Do you agree with this statement?

Without pervasive type annotations I’m not sure what you mean.  Can you 
elaborate more?  Even if foo is typed, “foo.bar.baz()” won’t be in general 
because Python does not have typed property declarations.

>> Finally, just MHO, but I don’t expect a lot of “mix and match" Python/Swift 
>> apps to exist (where the developer owns both the Python and the Swift code), 
>> which is one case where type annotations are super awesome in ObjC.  IMO, 
>> the most important use-case is a Swift program that uses some Python APIs.
> 
> Let’s consider Python type annotations to be useless for our purposes. None 
> of my argument hinges on it.

Good.  I’ll ignore them for the moment.

>> 
>> I didn’t realize that you were thinking we would literally use AnyObject 
>> itself.  I haven’t thought fully through it, but I think this will provide 
>> several problems:
> 
> You are correct that literally using AnyObject has these issues. There 
> appears to be a lot of confusion about what the AnyObject model *is*, so 
> let’s sort through that. I think it is reasonable to take the AnyObject model 
> and replicate it for PythonObject.

Ok, good, using literally AnyObject is super problematic in my opinion.

So your implementation approach suggestion is to:

1) Define a new builtin type PythonObject.  Is this a base class, a new nominal 
type, or something else?  I assume a base class.
2) It supports AnyObject-style lookup, so code completion works.
3) The database 

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

[Erica Sadun via swift-evolution]

On Dec 1, 2017, at 11:23 PM, David Waite  wrote:
> 
> 
> 
>> On Dec 1, 2017, at 11:05 AM, Erica Sadun via swift-evolution 
>> > wrote:
>> 
>> I'd like to put forth that Gameplay Kit offers a perfectly cromulent model 
>> of random number generation and API. Why not take that as a starting point, 
>> Swiftify it so it becomes a cross platform solution, and then apply the 
>> specific questions of sequences, collections, and indices as a second step?  
>> 
>> I don't support intermingling random functionality with existing core types.
>> 
> 
> GameplayKit randomization has a number of API deficiencies that we can’t 
> easily/efficiently solve by wrapping it in Swift.
> 
> Most significantly, it is not designed to support any cryptographic 
> operations (which I believe is why they never added a nextBytes() or 
> equivalent method).
> 
> For GameplayKit this is fine - the design focuses on being able to get the 
> distribution appropriate for your game, and being able to have identical 
> pseudorandom number sequences for each device in a multiplayer scenario. They 
> went as far as to require all random sources to support NSSecureCoding so 
> that they may be persisted and/or serialized over the wire, which precludes a 
> GKRandomSource from being based on the system random sources.
> 
> -DW

I wasn't suggesting wrapping as that would not provide a cross platform 
solution. Instead of re-inventing the wheel, we may profit from the approaches 
already explored and real-world tested in prior art and existing standards.

-- E

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

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

[Brent Royal-Gordon via swift-evolution]

> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> That said, I am not sure that this proposal should give any pretense of being 
> suitable for cryptographic use. On implementation, the code will not have 
> been audited for that purpose, although the author very rightly attempts to 
> use the "best" possible sources of entropy available for each platform. 
> Perhaps explicitly _not_ supporting cryptographic operations is the more 
> Swifty way to go (in the sense that, where possible, Swift API design aims to 
> help users avoid footguns).

People will use it for crypto whether we want them to or not.

None of the proposals involve actually writing cryptographic primitives, just 
calling out to well-known functions like `arc4random()` or reading from special 
devices like `/dev/urandom`. I would hope that Apple's security team can spare 
the time to review the security-critical parts and sign off on them, and I'd be 
perfectly happy to see this proposal be approved but the final merge into the 
language be deferred until they've taken a look at it.

-- 
Brent Royal-Gordon
Architechies

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