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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Dec 7, 2017, at 5:27 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> 
>> On Dec 2, 2017, at 9:23 PM, Dave Abrahams  wrote:
>> 
>> 
>>> On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution 
>>>  wrote:
>> 
>>> What’s a Good Solution Look Like?
>>> Our current system for associated type inference and associated type 
>>> defaults is buggy and complicated.
>> 
>> Well, that’s the problem, then.  Don’t worry, I won’t suggest that you 
>> simply fix the implementation, because even if there weren’t bugs and the 
>> system were predictable I’d still think we could improve the situation for 
>> users by making associated type default declarations more explicit.
>> 
>>> The compiler gets it right often enough that people depend on it, but I 
>>> don’t think anyone can reasonably be expected to puzzle out what’s going to 
>>> happen, and this area is rife with bugs. If we were to design a new 
>>> solution from scratch, what properties should it have?
>>> 
>>> It should allow the author of a protocol to provide reasonable defaults, so 
>>> the user doesn’t have to write them
>>> It shouldn’t require users to write typealiases for “obvious” cases, even 
>>> when they aren’t due to defaults
>>> It shouldn’t infer an inconsistent set of typealiases
>>> It should be something that a competent Swift programmer could reason about 
>>> when it will succeed, when and why it will fail, and what the resulting 
>>> inferred typealiases would be
>>> It should admit a reasonable implementation in the compiler that is 
>>> performant and robust
>> • It should cover all of the existing use cases.
>> • It should not break code at this point.
>> • We should have a migration strategy for existing code that avoids traps 
>> like silent semantic changes.
>> 
>> My bullet is important to me; I don’t think existing use cases are 
>> (inherently) so complex that we can sacrifice almost any of them and still 
>> end up with a sufficiently useful system.  At the very least, existing use 
>> cases provide the only guidance we really have as to what the feature should 
>> do.
> 
> I honestly don’t feel like a have a good handle on all of the use cases for 
> associated type inference, and it’s not something we can simply search for on 
> GitHub. But I think it covers most of them—and Matthew and Greg’s positive 
> feedback helps my confidence here. The biggest potential issue, I think, is 
> that we’ll no longer infer associated types from default implementations, 
> which protocol vendors might be relying on.

Hi Doug.  FWIW, I always explicitly state defaults in protocol declarations so 
inference in default implementations is something that I don’t use.  I think 
it’s very reasonable to require explicit declaration of the default.

There are a few areas where I can imagine a real impact.  The main one that I 
don’t think has been discussed yet is when conformance is declared in an 
extension but inference would need to consider a member declared in the 
original declaration.  This is likely to be pretty common given the requirement 
to declare stored properties in the original declaration and the common pattern 
of declaring conformance in an extension.  If implementation is feasible you 
might want to also consider the original declaration for a conformance that is 
stated in the same module (or even just the same file).

> 
>> 
>> I think we need to acknowledge that my second bullet is unattainable, at 
>> least if we want to improve type checking performance. Not breaking any code 
>> means that given any existing code, the compiler would have to explore the 
>> same solution space it currently does, and come up with the same answers.  
>> Improving performance would require new  declarations to use totally 
>> optional explicit syntax to prevent some explorations, and that’s an 
>> untenable user experience.
> 
> Yes, I agree.
> 
>> Which brings me to my third bullet: unless we are willing to break the code 
>> of protocol users (as opposed to vendors) we need to ensure that vendors can 
>> confidently convert code to use the new system without changing semantics.
> 
> Yeah, (2) below is basically that feature.
> 
>>  
>>> 
>>> A Rough Proposal
>>> I’ve been thinking about this for a bit, and I think there are three ways 
>>> in which we should be able to infer an associated type witness:
>>> 
>>> Associated type defaults, which are specified with the associated type 
>>> itself, e.g.,
>>> 
>>>   associatedtype Indices = DefaultIndices
>>> 
>>> These are easy to reason about for both the programmer and the compiler.
>>> Typealiases in (possibly constrained) protocol extensions, e.g.,
>>> 
>>>   extension RandomAccessCollection where Index : Strideable, Index.Stride 
>>> == IndexDistance {
>>> typealias RandomAccessCollection.Indices = CountableRange
>>>   }
>>> 
>>> I’m intentionally using some odd ‘.’ syntax 

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

[Letanyan Arumugam via swift-evolution]

> On 08 Dec 2017, at 00:06, Paul Cantrell  wrote:
> 
> 
>> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
>> 
>>> My main objection to the critical responses is that most of the objections 
>>> are fundamentally cultural, not technical, and are fear-based, not 
>>> evidence-based.
>> 
>> The goal of this proposal is to bring people from a culture where excessive 
>> use of this would be the norm for them. Why would it be so hard to imagine 
>> that people would adopt bad principles, knowing or unknowing, because this 
>> is what they’ve always done?
> 
> Languages bring in new developers who misapply their experience all the time. 
> Look at the early days of Ruby when it was actively working to pull new 
> developers away from Java, developers who were in the habit of using names 
> like AbstractItemManagerFactoryImpl. Look at beginner Swift code posted in 
> Stack Overflow questions, littered with careless force unwraps that are 
> clearly there because that’s the fixit and sort of smells like C or Java, not 
> because they actually thought about what they were doing.
> 
> Note in both cases how the center of gravity of the language did •not• move. 
> Note how poorly designed libraries that didn’t fit the language did •not• see 
> adoption. Note how the core community acted as good teachers to the newcomers.
> 
>> My fear is that a design pattern around dynamic members and calls arise that 
>> is used to bypass the perceived initial annoyance of Swifts type system from 
>> new developers that come over to Swift and are now starting to try and go 
>> native.
> 
> That contradicts the historical experience of other languages that have seen 
> “crossover” adoption from developers bringing very different mental models 
> with them.
> 
> A Swift library released today that senselessly used dynamic member lookup 
> without good engineering reason would go over just about as well as an 
> AbstractItemManagerFactoryImpl would have gone over with the Ruby community 
> in 2007.
> 
> Again, a language feature alone will not erase the good sense of the 
> language’s stewards, or poison its community.
> 
> People come to Swift to write Swift. People trying to write Python or Ruby or 
> C in Swift will feel the friction, learn from that, adjust their habits 
> taking a cue from the code they find in the surrounding ecosystem, and learn 
> to think “Swiftly.” This has been the case in every language before Swift; it 
> will not stop being the case now.
> 
> Joe hit this nail on the head:
> 
>> On Dec 7, 2017, at 10:08 AM, Joe DeCapo via swift-evolution 
>>  wrote:
>> 
>> When I began writing Python, I initially named all my variables in camel 
>> case. And when I used the Subprocess module, I was passing return codes 
>> throughout my code base like it was bash. Even though I didn't know what was 
>> idiomatic in Python at that time, I could still sense a code smell in what I 
>> was writing. I soon learned that snake case was the standard, so I updated 
>> my code. And eventually I learned how to use exceptions and I refactored my 
>> code to use them instead of return codes. I doubt that this is unusual when 
>> coming to a new language with previous experience in other languages. It 
>> seems inevitable, and a normal process for becoming familiar with the idioms 
>> of a certain language community. I don't think we need to be so fearful of 
>> the community fracturing if people from a dynamic language background come 
>> to Swift and initially use those idioms. It will always be more burdensome 
>> to do things in a non-idiomatic way, and over time people will learn how to 
>> write idiomatic Swift.
> 
> Exactly.
> 
>> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
>> 
>> Evidence is going to be hard to get since I don’t know any other language 
>> like Swift that has done this for the same reasons before. As far as C# goes 
>> were they trying to get people from a heavily based dynamic community or 
>> help those already in the community?
>> 
>>> If a little extra language ceremony helps assuage those fears, I guess I’d 
>>> consider it. I still think static analysis — starting and mostly ending 
>>> with boring old syntax coloring — answers most all the concerns people have 
>>> raised, and this debate is a tempest in a teapot.
>> 
>> I'm unsure of this, but as far as I’m aware Swift language proposals 
>> shouldn’t rely on editor features. But like I said I’m unsure of this and if 
>> someone could clarify this that would great.
> 
> Type inference effectively does, to at least the same degree as this 
> proposal. See my previous post reflecting on why Java chose not to have any 
> sort of type inference:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041926.html
> 
> • • •
> 
> It’s wise to remember Flon’s Law:
> 
> “There is not now, nor has there ever been, nor will there 

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

[Letanyan Arumugam via swift-evolution]

> On 07 Dec 2017, at 22:26, Chris Lattner  wrote:
> 
>> 
>> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam > > wrote:
>> 
> fatalError shouldn’t be used excessively. API surface areas for these 
> types are going to be massive (infinite technically). I assume many 
> people are going to be writing a lot of code would these types and 
> calling many methods and properties which would all essentially have a 
> fatalError. Would you consider it good code if the majority of all your 
> types had methods defined with fatalError calls.
> 
> What is the basis for this claim? Probably the majority of standard 
> library methods check preconditions and trap on failure. That is how I 
> write my code as well.
> 
 
 I’m talking specifically about fatalError not precondition. fatalError is 
 something that goes out with production code while precondition is used 
 for debugging. I think you would agree a shipped program that has many 
 states of being unrecoverable is not a good design?
>>> 
>>> You are aware that Int traps on overflow and arrays trap on out of bounds, 
>>> right?
>>> 
>> 
>> Were each of them not decided upon separately based on certain tradeoffs? 
>> Arrays for speed and Int overflow because having the addition operator 
>> return an optional would be too cumbersome? If these reasons were not so 
>> influential would they still be designed to trap?
> 
> Yes, each of these decisions was carefully made.  
> 
> My point is that pretty much all code can fail at runtime, including 
> "something that goes out with production code”, because integers and arrays 
> are pervasive. I do not understand your claim that Swift APIs do not 
> generally fail at runtime.
> 
> -Chris

I’m just saying that we should try to avoid failure at runtime as much as we 
can whenever we can. We shouldn’t think it’s okay to add more reasons to fail 
at runtime because there’s already reasons to fail. We should be trying to 
reduce these. And even if this is impossible I think its always good to try.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> On Dec 2, 2017, at 9:23 PM, Dave Abrahams  wrote:
> 
> 
> On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution 
> > wrote:
>> What’s a Good Solution Look Like?
>> Our current system for associated type inference and associated type 
>> defaults is buggy and complicated.
> 
> Well, that’s the problem, then.  Don’t worry, I won’t suggest that you simply 
> fix the implementation, because even if there weren’t bugs and the system 
> were predictable I’d still think we could improve the situation for users by 
> making associated type default declarations more explicit.
> 
>> The compiler gets it right often enough that people depend on it, but I 
>> don’t think anyone can reasonably be expected to puzzle out what’s going to 
>> happen, and this area is rife with bugs. If we were to design a new solution 
>> from scratch, what properties should it have?
>> 
>> It should allow the author of a protocol to provide reasonable defaults, so 
>> the user doesn’t have to write them
>> It shouldn’t require users to write typealiases for “obvious” cases, even 
>> when they aren’t due to defaults
>> It shouldn’t infer an inconsistent set of typealiases
>> It should be something that a competent Swift programmer could reason about 
>> when it will succeed, when and why it will fail, and what the resulting 
>> inferred typealiases would be
>> It should admit a reasonable implementation in the compiler that is 
>> performant and robust
> • It should cover all of the existing use cases.
> • It should not break code at this point.
> • We should have a migration strategy for existing code that avoids traps 
> like silent semantic changes.
> 
> My bullet is important to me; I don’t think existing use cases are 
> (inherently) so complex that we can sacrifice almost any of them and still 
> end up with a sufficiently useful system.  At the very least, existing use 
> cases provide the only guidance we really have as to what the feature should 
> do.

I honestly don’t feel like a have a good handle on all of the use cases for 
associated type inference, and it’s not something we can simply search for on 
GitHub. But I think it covers most of them—and Matthew and Greg’s positive 
feedback helps my confidence here. The biggest potential issue, I think, is 
that we’ll no longer infer associated types from default implementations, which 
protocol vendors might be relying on.

> 
> I think we need to acknowledge that my second bullet is unattainable, at 
> least if we want to improve type checking performance. Not breaking any code 
> means that given any existing code, the compiler would have to explore the 
> same solution space it currently does, and come up with the same answers.  
> Improving performance would require new  declarations to use totally optional 
> explicit syntax to prevent some explorations, and that’s an untenable user 
> experience.

Yes, I agree.

> Which brings me to my third bullet: unless we are willing to break the code 
> of protocol users (as opposed to vendors) we need to ensure that vendors can 
> confidently convert code to use the new system without changing semantics.

Yeah, (2) below is basically that feature.

>  
>> 
>> A Rough Proposal
>> I’ve been thinking about this for a bit, and I think there are three ways in 
>> which we should be able to infer an associated type witness:
>> 
>> Associated type defaults, which are specified with the associated type 
>> itself, e.g.,
>> 
>>   associatedtype Indices = DefaultIndices
>> 
>> These are easy to reason about for both the programmer and the compiler.
>> Typealiases in (possibly constrained) protocol extensions, e.g.,
>> 
>>   extension RandomAccessCollection where Index : Strideable, Index.Stride == 
>> IndexDistance {
>> typealias RandomAccessCollection.Indices = CountableRange
>>   }
>> 
>> I’m intentionally using some odd ‘.’ syntax here to indicate that this 
>> typealias is intended only to be found when trying to satisfy an associated 
>> type requirement, and is not a general typealias that could be found by 
>> normal name lookup. Let’s set the syntax bike shed aside for the moment. The 
>> primary advantage of this approach (vs. inferring Indices from “var Indices: 
>> CountableRange” in a constrained protocol extension) is that there’s 
>> a real typealias declaration that compiler and programmer alike can look at 
>> and reason about based just on the name “Indices”. 
>> 
>> Note that this mechanism technically obviates the need for (1), in the same 
>> sense that default implementations in protocols 
>> 
>>  are merely syntactic sugar.
>> Declarations within the nominal type declaration or extension that declares 
>> conformance to the protocol in question. This is generally the same approach 
>> as described in “associated type 

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

[Douglas Gregor via swift-evolution]

> On Dec 3, 2017, at 2:39 PM, Jens Persson  wrote:
> 
> Would this help sorting out the behavior of typealiases in constrained 
> extensions?

Sadly, no.

> 
> If not, please ignore the following and accept my apologies for posting OT.
> 
> Typealiases in constrained extensions are - and have been, for a long time - 
> very broken.
> The following program (which is clearly crazy in several ways) compiles and 
> runs using the latest version of the compiler:
> 
> struct S {
>   var v: This
> }
> extension S where T == Int {
>   typealias This = Is
> }
> extension S where T == Bool {
>   typealias Is = Fine
> }
> extension S where T == String {
>   typealias Fine = T
> }
> let x = S(v: "uh")
> print(x.v) // uh
> 
> ( SR-5440 )
> The current behavior is so allowing and strange that I'm having trouble 
> seeing what the correct behavior would be if things worked as intended.

I’d said that “var v: This”, “typealias This = Is”, and “typealias Is = Fine” 
are ill-formed and the compiler should reject them. You should only be able to 
use types from another extension if your extra constraints imply the 
constraints of that extension. I *think* it’s actually a simple model, but it 
didn’t get implemented.

> For example should the following program still compile, and if so, should the 
> last line also compile (if uncommented)?
> 
> protocol P {
> associatedtype A = Int
> associatedtype B = Bool
> typealias C = Float
> }
> extension P where B == A {
> typealias C = String
> }

I think this should be ill-formed, because we shouldn’t allow two typealiases 
with the same name to “overload” within the same type.

> struct S : P {
> var v: (A, B, C)
> }
> extension S where A == Int, B == Bool {
> typealias C = [String]
> }
> let s1 = S(v: (1, true, [""]))
> // let s2 = S(v: ("a", "b", "c")) // Not (currently) ok.
> 
> Again, sorry for the noise if this is unrelated to the discussion.

- Doug

> /Jens
> 
> 
> On Sun, Dec 3, 2017 at 6:23 AM, Dave Abrahams via swift-evolution 
> > wrote:
> 
> 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 
>> 

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

[Douglas Gregor via swift-evolution]

> On Dec 1, 2017, at 11:42 AM, Nevin Brackett-Rozinsky 
>  wrote:
> 
> On Thu, Nov 30, 2017 at 7:28 PM, Douglas Gregor via swift-evolution 
> > wrote:
> A Rough Proposal
> I’ve been thinking about this for a bit, and I think there are three ways in 
> which we should be able to infer an associated type witness:
> 
> Associated type defaults, which are specified with the associated type 
> itself, e.g.,
> 
>   associatedtype Indices = DefaultIndices
> 
> These are easy to reason about for both the programmer and the compiler.
> Typealiases in (possibly constrained) protocol extensions, e.g.,
> 
>   extension RandomAccessCollection where Index : Strideable, Index.Stride == 
> IndexDistance {
> typealias RandomAccessCollection.Indices = CountableRange
>   }
> 
> I’m intentionally using some odd ‘.’ syntax here to indicate that this 
> typealias is intended only to be found when trying to satisfy an associated 
> type requirement, and is not a general typealias that could be found by 
> normal name lookup. Let’s set the syntax bike shed aside for the moment. The 
> primary advantage of this approach (vs. inferring Indices from “var Indices: 
> CountableRange” in a constrained protocol extension) is that there’s a 
> real typealias declaration that compiler and programmer alike can look at and 
> reason about based just on the name “Indices”. 
> 
> Note that this mechanism technically obviates the need for (1), in the same 
> sense that default implementations in protocols 
> 
>  are merely syntactic sugar.
> Declarations within the nominal type declaration or extension that declares 
> conformance to the protocol in question. This is generally the same approach 
> as described in “associated type inference” above, where we match 
> requirements of the protocol against declarations that could satisfy those 
> requirements and infer associated types from there. However, I want to turn 
> it around: instead of starting with the requirements of the protocol any 
> looking basically anywhere in the type or any protocol to which it conforms 
> (for implementations in protocol extensions), start with the declarations 
> that the user explicitly wrote at the point of the conformance and look for 
> requirements they might satisfy. For example, consider our initial example:
> 
>   extension MyCollection: RandomAccessCollection {
> var startIndex: Int { return contents.startIndex }
> var endIndex: Int { return contents.endIndex }
> subscript(index: Int) -> T { return contents[index] }
>   }
> 
> Since startIndex, endIndex, and subscript(_:) are declared in the same 
> extension that declares conformance to RandomAccessIterator, we should look 
> for requirements with the same name as these properties and subscript within 
> RandomAccessCollection (or any protocol it inherits) and infer Index := Int 
> and Element := T by matching the type signatures. This is still the most 
> magical inference rule, because there is no declaration named “Index” or 
> “Element” to look at. However, it is much narrower in scope than the current 
> implementation, because it’s only going to reason from the (probably small) 
> set of declarations that the user wrote alongside the conformance, so it’s 
> more likely to be intentional. Note that this is again nudging programmers 
> toward the style of programming where one puts one protocol conformance per 
> extension, which is admittedly my personal preference.
> 
> Thoughts?
> I think this approach is more predictable and more implementable than the 
> current model. I’m curious whether the above makes sense to someone other 
> than me, and whether it covers existing use cases well enough. Thoughts?
> 
>   - Doug
> 
> 
> How does this work with retroactive conformance, especially where all the 
> protocol requirements already exist on a type and an empty extension declares 
> conformance? For example, suppose Module A declares a protocol with 
> associated types, and Module B has a struct which naturally possesses all the 
> required members to conform (maybe B handles Double concretely, while A can 
> work with any FloatingPoint, or some such). As a client importing both 
> modules and providing an empty extension to conform B’s struct to A’s 
> protocol, will the associated types be inferred?

No, the associated types will not be inferred in this case. That will be a 
change in behavior (and a source compatibility regression).

> Also, have you considered the possibility of allowing protocol authors to 
> specify which types should be inferred from which requirements? For example 
> Collection might demarcate “startIndex” as the source-of-truth for inferring 
> “Index”, and “subscript (Index)->Element” as the source-of-truth for 
> inferring “Element”.

This did 

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

[Chris Lattner via swift-evolution]

> On Dec 7, 2017, at 2:07 PM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> 
>> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
>> 
>>> My main objection to the critical responses is that most of the objections 
>>> are fundamentally cultural, not technical, and are fear-based, not 
>>> evidence-based.
>> 
>> The goal of this proposal is to bring people from a culture where excessive 
>> use of this would be the norm for them. Why would it be so hard to imagine 
>> that people would adopt bad principles, knowing or unknowing, because this 
>> is what they’ve always done?
> 
> Languages bring in new developers who misapply their experience all the time. 
> Look at the early days of Ruby when it was actively working to pull new 
> developers away from Java, developers who were in the habit of using names 
> like AbstractItemManagerFactoryImpl. Look at beginner Swift code posted in 
> Stack Overflow questions, littered with careless force unwraps that are 
> clearly there because that’s the fixit and sort of smells like C or Java, not 
> because they actually thought about what they were doing.

Great post Paul.  Similarly, look at the early days of Swift, where many ObjC 
programmers used IOUs for everything.

Bad code gets written all the time, this is unavoidable.  This feature will not 
affect or measurably change that.

-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

[Paul Cantrell via swift-evolution]

> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
> 
>> My main objection to the critical responses is that most of the objections 
>> are fundamentally cultural, not technical, and are fear-based, not 
>> evidence-based.
> 
> The goal of this proposal is to bring people from a culture where excessive 
> use of this would be the norm for them. Why would it be so hard to imagine 
> that people would adopt bad principles, knowing or unknowing, because this is 
> what they’ve always done?

Languages bring in new developers who misapply their experience all the time. 
Look at the early days of Ruby when it was actively working to pull new 
developers away from Java, developers who were in the habit of using names like 
AbstractItemManagerFactoryImpl. Look at beginner Swift code posted in Stack 
Overflow questions, littered with careless force unwraps that are clearly there 
because that’s the fixit and sort of smells like C or Java, not because they 
actually thought about what they were doing.

Note in both cases how the center of gravity of the language did •not• move. 
Note how poorly designed libraries that didn’t fit the language did •not• see 
adoption. Note how the core community acted as good teachers to the newcomers.

> My fear is that a design pattern around dynamic members and calls arise that 
> is used to bypass the perceived initial annoyance of Swifts type system from 
> new developers that come over to Swift and are now starting to try and go 
> native.

That contradicts the historical experience of other languages that have seen 
“crossover” adoption from developers bringing very different mental models with 
them.

A Swift library released today that senselessly used dynamic member lookup 
without good engineering reason would go over just about as well as an 
AbstractItemManagerFactoryImpl would have gone over with the Ruby community in 
2007.

Again, a language feature alone will not erase the good sense of the language’s 
stewards, or poison its community.

People come to Swift to write Swift. People trying to write Python or Ruby or C 
in Swift will feel the friction, learn from that, adjust their habits taking a 
cue from the code they find in the surrounding ecosystem, and learn to think 
“Swiftly.” This has been the case in every language before Swift; it will not 
stop being the case now.

Joe hit this nail on the head:

> On Dec 7, 2017, at 10:08 AM, Joe DeCapo via swift-evolution 
>  wrote:
> 
> When I began writing Python, I initially named all my variables in camel 
> case. And when I used the Subprocess module, I was passing return codes 
> throughout my code base like it was bash. Even though I didn't know what was 
> idiomatic in Python at that time, I could still sense a code smell in what I 
> was writing. I soon learned that snake case was the standard, so I updated my 
> code. And eventually I learned how to use exceptions and I refactored my code 
> to use them instead of return codes. I doubt that this is unusual when coming 
> to a new language with previous experience in other languages. It seems 
> inevitable, and a normal process for becoming familiar with the idioms of a 
> certain language community. I don't think we need to be so fearful of the 
> community fracturing if people from a dynamic language background come to 
> Swift and initially use those idioms. It will always be more burdensome to do 
> things in a non-idiomatic way, and over time people will learn how to write 
> idiomatic Swift.

Exactly.

> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
> 
> Evidence is going to be hard to get since I don’t know any other language 
> like Swift that has done this for the same reasons before. As far as C# goes 
> were they trying to get people from a heavily based dynamic community or help 
> those already in the community?
> 
>> If a little extra language ceremony helps assuage those fears, I guess I’d 
>> consider it. I still think static analysis — starting and mostly ending with 
>> boring old syntax coloring — answers most all the concerns people have 
>> raised, and this debate is a tempest in a teapot.
> 
> I'm unsure of this, but as far as I’m aware Swift language proposals 
> shouldn’t rely on editor features. But like I said I’m unsure of this and if 
> someone could clarify this that would great.

Type inference effectively does, to at least the same degree as this proposal. 
See my previous post reflecting on why Java chose not to have any sort of type 
inference:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041926.html

• • •

It’s wise to remember Flon’s Law:

“There is not now, nor has there ever been, nor will there ever be, any 
programming language in which it is the least bit difficult to write bad code.”

We should design languages to make writing excellent code as pleasant and 
rewarding as possible. Or more accurately, we should 

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

[Chris Lattner via swift-evolution]

> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam  wrote:
> 
 fatalError shouldn’t be used excessively. API surface areas for these 
 types are going to be massive (infinite technically). I assume many people 
 are going to be writing a lot of code would these types and calling many 
 methods and properties which would all essentially have a fatalError. 
 Would you consider it good code if the majority of all your types had 
 methods defined with fatalError calls.
 
 What is the basis for this claim? Probably the majority of standard 
 library methods check preconditions and trap on failure. That is how I 
 write my code as well.
 
>>> 
>>> I’m talking specifically about fatalError not precondition. fatalError is 
>>> something that goes out with production code while precondition is used for 
>>> debugging. I think you would agree a shipped program that has many states 
>>> of being unrecoverable is not a good design?
>> 
>> You are aware that Int traps on overflow and arrays trap on out of bounds, 
>> right?
>> 
> 
> Were each of them not decided upon separately based on certain tradeoffs? 
> Arrays for speed and Int overflow because having the addition operator return 
> an optional would be too cumbersome? If these reasons were not so influential 
> would they still be designed to trap?

Yes, each of these decisions was carefully made.  

My point is that pretty much all code can fail at runtime, including "something 
that goes out with production code”, because integers and arrays are pervasive. 
I do not understand your claim that Swift APIs do not generally fail at runtime.

-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

[Letanyan Arumugam via swift-evolution]

Regards

Letanyan Arumugam



> On 07 Dec 2017, at 21:07, Chris Lattner  wrote:
> 
> 
>> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>>> On 07 Dec 2017, at 17:02, Xiaodi Wu >> > wrote:
>>> 
>>> 
>>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>>> > wrote:
>>> 
 This seems marginally tolerable, but excessive.
 
 Do we mark every usage of a type that can generate precondition failures 
 or fatal errors for reasons other than “no such method?” No, we don’t.
 
>>> 
>>> fatalError shouldn’t be used excessively. API surface areas for these types 
>>> are going to be massive (infinite technically). I assume many people are 
>>> going to be writing a lot of code would these types and calling many 
>>> methods and properties which would all essentially have a fatalError. Would 
>>> you consider it good code if the majority of all your types had methods 
>>> defined with fatalError calls.
>>> 
>>> What is the basis for this claim? Probably the majority of standard library 
>>> methods check preconditions and trap on failure. That is how I write my 
>>> code as well.
>>> 
>> 
>> I’m talking specifically about fatalError not precondition. fatalError is 
>> something that goes out with production code while precondition is used for 
>> debugging. I think you would agree a shipped program that has many states of 
>> being unrecoverable is not a good design?
> 
> You are aware that Int traps on overflow and arrays trap on out of bounds, 
> right?
> 

Were each of them not decided upon separately based on certain tradeoffs? 
Arrays for speed and Int overflow because having the addition operator return 
an optional would be too cumbersome? If these reasons were not so influential 
would they still be designed to trap?

___
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 7, 2017, at 9:20 AM, BJ Homer via swift-evolution 
>  wrote:
> 
>> So while it’s theoretically possible to do this, I don’t think it’s a 
>> concern in practice. The incentives are already in place to encourage doing 
>> the “right” thing in this case, even with the possibility of dynamic member 
>> lookup.
>> 
>> -BJ
>> 
>> Hey, thanks for answering that part of the concern. i also came to this 
>> point, but wondered if the dictionary couldn't be made of type [String: 
>> DynamicValue] where DynamicValue would have some way to be  automatically 
>> casted to string, int, etc, by reusing the same mechanism that the proposal 
>> would use to convert PyVal to regular swift types. I stopped at this point.
>> 
> 
> 
> As far as I am aware, the proposal provides no mechanism for automatically 
> converting back from PyVal to regular Swift types. You would have to do 
> something explicit like myPythonValue.intValue, or String(myPythonValue).

That is correct, these proposals have nothing to do with conversions like that.

If you look at the Python prototype I sent out, the primitive types like 
Int/String/etc have failable conversion from PyVal (they return an optional).

-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 Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution 
>  wrote:
> 
> 
> 
>> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote:
>> 
>> 
>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>> > wrote:
>> 
>>> This seems marginally tolerable, but excessive.
>>> 
>>> Do we mark every usage of a type that can generate precondition failures or 
>>> fatal errors for reasons other than “no such method?” No, we don’t.
>>> 
>> 
>> fatalError shouldn’t be used excessively. API surface areas for these types 
>> are going to be massive (infinite technically). I assume many people are 
>> going to be writing a lot of code would these types and calling many methods 
>> and properties which would all essentially have a fatalError. Would you 
>> consider it good code if the majority of all your types had methods defined 
>> with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard library 
>> methods check preconditions and trap on failure. That is how I write my code 
>> as well.
>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is 
> something that goes out with production code while precondition is used for 
> debugging. I think you would agree a shipped program that has many states of 
> being unrecoverable is not a good design?

You are aware that Int traps on overflow and arrays trap on out of bounds, 
right?

-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

[Letanyan Arumugam via swift-evolution]

So the idea is that we shouldn’t allow dynamic lookups and calls to return 
values without some sort of error handling by default. Avoiding error handling 
should be an opt in situation. The point of having the default behaviour 
require error handling is that these protocols will always have at least one 
failure to handle.

Dynamic calls would work in much the same way as a lookup. Calls should require 
that they return an Optional or throw by default. You can then opt in to have 
the ability to return whatever you want however you want.

Remember these errors have no meaning specific to "something doesn’t exist". 
It’s whatever we want them to mean. 
However you want to model your call is up to you. If you want to just return 
Void, for whatever reason, opt in and do so just as long you are sure.

I understand that this seems like an unnecessary hinderance, but most forms of 
security/protection is.

> On 07 Dec 2017, at 19:47, Joe DeCapo  wrote:
> 
> 
>> On Dec 7, 2017, at 11:29 AM, Letanyan Arumugam > > wrote:
>> 
>> I think a better approach would still be to try and get the author of the 
>> type to make the right choice in the first place.
> 
> After rereading the post you linked to last night 
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042015.html
>  
> ),
>  I think it could quickly get out of hand. It might be simple enough for 
> DynamicMemberLookup, but once we get to the point of discussing 
> DynamicCallable there are many more variations.
> 
> - Calls that return Void
Opt in to unchecked behaviour and return a Void

> - Calls that return an optional

Return an optional of an optional if you wish.
Or throw a “doesntExist" and return an optional
Just return an optional and ignore the “doesn’t exist meaning” or have it imply 
either

However you want to model it do so

> - Calls that return an IUO
Opt in and return an IUO if thats the right design

> - Calls that throw
> - etc.
> 
> I know this is a discussion about DynamicMemberLookup, but DynamicCallable is 
> closely related and I imagine will end up following a similar pattern. How 
> would you propose that DynamicCallable would be annotated in this fashion? 
> There are a number of types of calls, and some are orthogonal so the 
> combinations quickly add up. People will probably have similar concerns about 
> failed call lookups as they do about member lookups.



___
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

[Joe DeCapo via swift-evolution]

> On Dec 7, 2017, at 11:29 AM, Letanyan Arumugam  wrote:
> 
> I think a better approach would still be to try and get the author of the 
> type to make the right choice in the first place.

After rereading the post you linked to last night 
(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042015.html
 
),
 I think it could quickly get out of hand. It might be simple enough for 
DynamicMemberLookup, but once we get to the point of discussing DynamicCallable 
there are many more variations.

- Calls that return Void
- Calls that return an optional
- Calls that return an IUO
- Calls that throw
- etc.

I know this is a discussion about DynamicMemberLookup, but DynamicCallable is 
closely related and I imagine will end up following a similar pattern. How 
would you propose that DynamicCallable would be annotated in this fashion? 
There are a number of types of calls, and some are orthogonal so the 
combinations quickly add up. People will probably have similar concerns about 
failed call lookups as they do about member lookups.___
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

[Benjamin G via swift-evolution]

Reading this part of the proposal
"Now clients are able to write more natural code like:
json[0]?.name?.first?.stringValue which is close to the expressivity of
Javascript... while being fully type safe!"

gave me the feeling that communication between dynamiclookupable types and
static swift types was aimed at being quite seamless.
Now having to write ".string or .int" in the end of the dynamic expression
would indeed raise the bar a bit, but i'm still very skeptical this would
be enough to deter people from trying to import "dynamic magic"  into
swift.



On Thu, Dec 7, 2017 at 6:20 PM, BJ Homer  wrote:

>
>
> On Dec 7, 2017, at 10:16 AM, Benjamin G 
> wrote:
>
>
>
> On Thu, Dec 7, 2017 at 6:01 PM, BJ Homer  wrote:
>
>> Benjamin,
>>
>> It sounds like your concern is that people might write objects that just
>> store everything in a dictionary, instead of declaring typed properties.
>> Correct?
>>
>> On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I think i answered that question many times as well (by masquerading
>> dictionaries as regular classes), but if what i'm saying is simply
>> impossible because of Swift type system even with the new proposal, i'd
>> rather people tell it to me than ask the same question over and over..
>>
>> ___
>>
>>
>> It *would* be possible, in theory, to write a class that used a
>> dictionary as a backing store for all its properties under this proposal.
>> However, the dictionary would have to be typed [String: Any?], and every
>> property access would be typed Any?. Your code would look like this:
>>
>> class MyDynamicObject: DynamicMemberLookupProtocol {
>> var storage: [String: Any?] = [:]
>>
>> subscript(dynamicMember: String) -> Any? {
>> get { return storage[dynamicMember] }
>> set(newValue) { storage[dynamicMember] = newValue }
>> }
>> }
>>
>> let x: MyDynamicObject = ...
>>
>> // setting properties is easy!
>> x.name = “Benjamin”
>> x.age = 3
>>
>> // using them, though, is hard!
>> var adults: [String] = []
>> if x.age as! Int > 18 {
>> adults.append(x.name as! String)
>> }
>>
>>
>> If you decide to create an object that stores everything in an ‘Any’,
>> Swift is going to force you to use an ‘as’ cast anytime you want to use
>> it. That’s super annoying.
>>
>> So yes, it’s possible to create a type that masquerades a dictionary as a
>> regular class. But the ergonomics of doing so are sufficiently frustrating
>> that nobody is likely to do so. Swift makes it easy to declare typed
>> variables here, and the user experience for doing so is vastly improved
>> (code completion, compile-time checking, no more ‘as’ casting, etc).
>>
>> So while it’s theoretically possible to do this, I don’t think it’s a
>> concern in practice. The incentives are already in place to encourage doing
>> the “right” thing in this case, even with the possibility of dynamic member
>> lookup.
>>
>> -BJ
>>
>
> Hey, thanks for answering that part of the concern. i also came to this
> point, but wondered if the dictionary couldn't be made of type [String:
> DynamicValue] where DynamicValue would have some way to be  automatically
> casted to string, int, etc, by reusing the same mechanism that the proposal
> would use to convert PyVal to regular swift types. I stopped at this point.
>
>
> As far as I am aware, the proposal provides no mechanism for automatically
> converting back from PyVal to regular Swift types. You would have to do
> something explicit like myPythonValue.intValue, or String(myPythonValue).
>
> -BJ
>
>
___
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

[Letanyan Arumugam via swift-evolution]

> On 07 Dec 2017, at 18:59, Joe DeCapo  wrote:
> 
> 
>> On Dec 7, 2017, at 10:41 AM, Letanyan Arumugam > > wrote:
>> 
>> I think warning and error messages would be too much. I’m not concerned 
>> about things being implemented in this way just as long as it’s appropriate. 
>> I would think all language layers like Python should have trapping lookups 
>> and calls.
> 
> To be clear, I meant a message that shows up in the console, not something 
> like a warning in the IDE. Similar to messages about autolayout constraints 
> being violated, or something of that nature.

I think a better approach would still be to try and get the author of the type 
to make the right choice in the first place.___
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

[Letanyan Arumugam via swift-evolution]

> 
>> The current design says that dynamic and static calls are on equal footing. 
>> This implies to the programmer that either way of doing things is correct. A 
>> programmer from a dynamic environment is usually going to choose the dynamic 
>> way because it’s more powerful and easier to use. I just merely want the 
>> design to have a way of showing the programmer that they should think twice 
>> about using it in an implicitly failing way. Whether that be renaming the 
>> protocol to something like UnsafeDynamicMemberLookup or something else along 
>> the lines of what Swift currently does.
> 
> I though the current design was all about easing the use of good libraries 
> that are currently only available in dynamic languages.
> 
> Do you aim at a particular paragraph in 
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context
>  ?
> 


Sorry I meant that the current design implies that dynamic and static 
calls/lookups are on equal footing (If not equal then very close). This is 
because conformance to DynamicMemberLookup is really easy.

This wasn’t about the motivation section specifically.
___
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

[BJ Homer via swift-evolution]

> On Dec 7, 2017, at 10:16 AM, Benjamin G  wrote:
> 
> 
> 
> On Thu, Dec 7, 2017 at 6:01 PM, BJ Homer  > wrote:
> Benjamin, 
> 
> It sounds like your concern is that people might write objects that just 
> store everything in a dictionary, instead of declaring typed properties. 
> Correct?
> 
>> On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution 
>> > wrote:
>> 
>> I think i answered that question many times as well (by masquerading 
>> dictionaries as regular classes), but if what i'm saying is simply 
>> impossible because of Swift type system even with the new proposal, i'd 
>> rather people tell it to me than ask the same question over and over..
>> 
>> ___
> 
> It would be possible, in theory, to write a class that used a dictionary as a 
> backing store for all its properties under this proposal. However, the 
> dictionary would have to be typed [String: Any?], and every property access 
> would be typed Any?. Your code would look like this:
> 
> class MyDynamicObject: DynamicMemberLookupProtocol {
> var storage: [String: Any?] = [:]
> 
> subscript(dynamicMember: String) -> Any? {
> get { return storage[dynamicMember] }
> set(newValue) { storage[dynamicMember] = newValue }
> }
> }
> 
> let x: MyDynamicObject = ...
> 
> // setting properties is easy!
> x.name  = “Benjamin”
> x.age = 3
> 
> // using them, though, is hard!
> var adults: [String] = []
> if x.age as! Int > 18 {
> adults.append(x.name  as! String)
> }
> 
> If you decide to create an object that stores everything in an ‘Any’, Swift 
> is going to force you to use an ‘as’ cast anytime you want to use it. That’s 
> super annoying.
> 
> So yes, it’s possible to create a type that masquerades a dictionary as a 
> regular class. But the ergonomics of doing so are sufficiently frustrating 
> that nobody is likely to do so. Swift makes it easy to declare typed 
> variables here, and the user experience for doing so is vastly improved (code 
> completion, compile-time checking, no more ‘as’ casting, etc).
> 
> So while it’s theoretically possible to do this, I don’t think it’s a concern 
> in practice. The incentives are already in place to encourage doing the 
> “right” thing in this case, even with the possibility of dynamic member 
> lookup.
> 
> -BJ
> 
> Hey, thanks for answering that part of the concern. i also came to this 
> point, but wondered if the dictionary couldn't be made of type [String: 
> DynamicValue] where DynamicValue would have some way to be  automatically 
> casted to string, int, etc, by reusing the same mechanism that the proposal 
> would use to convert PyVal to regular swift types. I stopped at this point.
> 


As far as I am aware, the proposal provides no mechanism for automatically 
converting back from PyVal to regular Swift types. You would have to do 
something explicit like myPythonValue.intValue, or String(myPythonValue).

-BJ

___
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

[Benjamin G via swift-evolution]

On Thu, Dec 7, 2017 at 6:01 PM, BJ Homer  wrote:

> Benjamin,
>
> It sounds like your concern is that people might write objects that just
> store everything in a dictionary, instead of declaring typed properties.
> Correct?
>
> On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think i answered that question many times as well (by masquerading
> dictionaries as regular classes), but if what i'm saying is simply
> impossible because of Swift type system even with the new proposal, i'd
> rather people tell it to me than ask the same question over and over..
>
> ___
>
>
> It *would* be possible, in theory, to write a class that used a
> dictionary as a backing store for all its properties under this proposal.
> However, the dictionary would have to be typed [String: Any?], and every
> property access would be typed Any?. Your code would look like this:
>
> class MyDynamicObject: DynamicMemberLookupProtocol {
> var storage: [String: Any?] = [:]
>
>
> subscript(dynamicMember: String) -> Any? {
> get { return storage[dynamicMember] }
> set(newValue) { storage[dynamicMember] = newValue }
> }
> }
>
> let x: MyDynamicObject = ...
>
> // setting properties is easy!
> x.name = “Benjamin”
> x.age = 3
>
> // using them, though, is hard!
> var adults: [String] = []
> if x.age as! Int > 18 {
> adults.append(x.name as! String)
> }
>
>
> If you decide to create an object that stores everything in an ‘Any’,
> Swift is going to force you to use an ‘as’ cast anytime you want to use
> it. That’s super annoying.
>
> So yes, it’s possible to create a type that masquerades a dictionary as a
> regular class. But the ergonomics of doing so are sufficiently frustrating
> that nobody is likely to do so. Swift makes it easy to declare typed
> variables here, and the user experience for doing so is vastly improved
> (code completion, compile-time checking, no more ‘as’ casting, etc).
>
> So while it’s theoretically possible to do this, I don’t think it’s a
> concern in practice. The incentives are already in place to encourage doing
> the “right” thing in this case, even with the possibility of dynamic member
> lookup.
>
> -BJ
>

Hey, thanks for answering that part of the concern. i also came to this
point, but wondered if the dictionary couldn't be made of type [String:
DynamicValue] where DynamicValue would have some way to be  automatically
casted to string, int, etc, by reusing the same mechanism that the proposal
would use to convert PyVal to regular swift types. I stopped at this point.
___
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

[BJ Homer via swift-evolution]

Benjamin, 

It sounds like your concern is that people might write objects that just store 
everything in a dictionary, instead of declaring typed properties. Correct?

> On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution 
>  wrote:
> 
> I think i answered that question many times as well (by masquerading 
> dictionaries as regular classes), but if what i'm saying is simply impossible 
> because of Swift type system even with the new proposal, i'd rather people 
> tell it to me than ask the same question over and over..
> 
> ___

It would be possible, in theory, to write a class that used a dictionary as a 
backing store for all its properties under this proposal. However, the 
dictionary would have to be typed [String: Any?], and every property access 
would be typed Any?. Your code would look like this:

class MyDynamicObject: DynamicMemberLookupProtocol {
var storage: [String: Any?] = [:]

subscript(dynamicMember: String) -> Any? {
get { return storage[dynamicMember] }
set(newValue) { storage[dynamicMember] = newValue }
}
}

let x: MyDynamicObject = ...

// setting properties is easy!
x.name = “Benjamin”
x.age = 3

// using them, though, is hard!
var adults: [String] = []
if x.age as! Int > 18 {
adults.append(x.name as! String)
}

If you decide to create an object that stores everything in an ‘Any’, Swift is 
going to force you to use an ‘as’ cast anytime you want to use it. That’s super 
annoying.

So yes, it’s possible to create a type that masquerades a dictionary as a 
regular class. But the ergonomics of doing so are sufficiently frustrating that 
nobody is likely to do so. Swift makes it easy to declare typed variables here, 
and the user experience for doing so is vastly improved (code completion, 
compile-time checking, no more ‘as’ casting, etc).

So while it’s theoretically possible to do this, I don’t think it’s a concern 
in practice. The incentives are already in place to encourage doing the “right” 
thing in this case, even with the possibility of dynamic member lookup.

-BJ___
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

[Joe DeCapo via swift-evolution]

> On Dec 7, 2017, at 10:41 AM, Letanyan Arumugam  wrote:
> 
> I think warning and error messages would be too much. I’m not concerned about 
> things being implemented in this way just as long as it’s appropriate. I 
> would think all language layers like Python should have trapping lookups and 
> calls.

To be clear, I meant a message that shows up in the console, not something like 
a warning in the IDE. Similar to messages about autolayout constraints being 
violated, or something of that nature.___
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

[Gwendal Roué via swift-evolution]

>>> I’m talking specifically about fatalError not precondition. fatalError is 
>>> something that goes out with production code while precondition is used for 
>>> debugging. I think you would agree a shipped program that has many states 
>>> of being unrecoverable is not a good design?
>> 
>> When a question is framed so that there is only one possible answer, the 
>> question is flawed.
>> 
>> The question is not whether one likes dynamism or not (the answer is pretty 
>> obvious for many people here, and we don't learn much).
> 
> One might call that a rhetorical question :) Which is probably not 
> appropriate here so I apologies for that.

It's difficult to avoid sometimes ;-)

>> It isn't if one would use the discussed features if the proposals were 
>> accepted (many here would swear they wouldn't, even if many of them will 
>> lick those dynamic features like candy, whenever appropriate, as every sane 
>> person would).
>> 
> I’m not sure anyone here ever said they wouldn’t use it. There’s just a 
> concern about how much it would be used.

Yes. And we all share this concern. Or, to put it better, I think : many Swift 
users are sold to the static safety of Swift.

Long gone are the early days when early Swift users were missing ObjC dynamism.

I may live in an echo chamber, but most Swift news I read are about strongly 
typed patterns, and the immense progress in the implementation of the Generics 
Manisfesto, which will bring even more type-safe goodness!

I thus see no threat in Chris's proposal. He even slightly obfuscates the 
identifiers so that no one jumps in by mistake.

>> Currently, it's a static vs. dynamic debate. But we should talk about a 
>> precise proposal, and a good one after that, which comes with plenty of 
>> information, and even playgrounds to look at!
> 
> I’m not taking sides on which is better (each to their own use cases). I am 
> talking about the proposals current design.

+1

> The current design says that dynamic and static calls are on equal footing. 
> This implies to the programmer that either way of doing things is correct. A 
> programmer from a dynamic environment is usually going to choose the dynamic 
> way because it’s more powerful and easier to use. I just merely want the 
> design to have a way of showing the programmer that they should think twice 
> about using it in an implicitly failing way. Whether that be renaming the 
> protocol to something like UnsafeDynamicMemberLookup or something else along 
> the lines of what Swift currently does.

I though the current design was all about easing the use of good libraries that 
are currently only available in dynamic languages.

Do you aim at a particular paragraph in 
https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context
 ?

Gwendal

___
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

[Joe DeCapo via swift-evolution]

> On Dec 7, 2017, at 10:12 AM, Letanyan Arumugam via swift-evolution 
>  wrote:
> 
> My original argument about failing for no discernible reason still stands. 
> precondition is a thought out check for a failing state. member lookup 
> failures are going to be because things don’t exist for which you presumably 
> expected to exist.

Is it necessarily true that things will have to fail "for no discernible 
reason"? It's up to the implementers of the protocol for how they want to 
handle the failure case (trap/return option/throw error/etc.). But I imagine it 
could be possible to add a generic debug error message/warning message about 
lookup failing for invocations of this kind, which would give a pretty clear 
hint about what went wrong and why. Would that be enough to address your 
concerns about silent failures?___
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

[C. Keith Ray via swift-evolution]

RPC predates NSProxy. The "type-safe" version of RPC was CORBA: anybody here 
use that? 

Then there was XML-RPC and then SOAP. 

The most popular version of RPC is HTTP + JSON, because http isn't blocked at 
network boundaries and because JSON was friendly to JavaScript in the browser.

So... Typesafe lost, stringly-typed won.

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Dec 7, 2017, at 7:39 AM, Gwendal Roué  wrote:
> 
> 
>> Le 7 déc. 2017 à 16:33, C. Keith Ray via swift-evolution 
>>  a écrit :
>> 
>> Let's see what disasters were created by people abusing NSProxy, the ObjC 
>> moral equivalent of a dynamic member lookup type.
>> 
>> I'm not aware of anything.
> 
> 
> I'm sure you are ;-)
> 
> I'm not expert at all of early ObjC... But wasn't NSProxy the base of 
> good-old-times RPC?
> 
> OK, in 2017 we know that RPC is dangerous. For example, when `() -> Int` 
> relies on a network call, it's almost impossible to handle errors.
> 
> But still, is it because an API can be used for bad things that an API is bad?
> 
> Gwendal
> 
___
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

[Letanyan Arumugam via swift-evolution]

> On 07 Dec 2017, at 17:46, Xiaodi Wu  wrote:
> 
> On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam  > wrote:
> 
> 
>> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote:
>> 
>> 
>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>> > wrote:
>> 
>>> This seems marginally tolerable, but excessive.
>>> 
>>> Do we mark every usage of a type that can generate precondition failures or 
>>> fatal errors for reasons other than “no such method?” No, we don’t.
>>> 
>> 
>> fatalError shouldn’t be used excessively. API surface areas for these types 
>> are going to be massive (infinite technically). I assume many people are 
>> going to be writing a lot of code would these types and calling many methods 
>> and properties which would all essentially have a fatalError. Would you 
>> consider it good code if the majority of all your types had methods defined 
>> with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard library 
>> methods check preconditions and trap on failure. That is how I write my code 
>> as well.
>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is 
> something that goes out with production code while precondition is used for 
> debugging. I think you would agree a shipped program that has many states of 
> being unrecoverable is not a good design?
> 
> Precondition checks are active in release code. When a program encounters 
> conditions that have no obvious recovery, trapping immediately is the only 
> safe option; this is what Swift means by “safety” and the practice is 
> encouraged.
> 

Apologies I was looking at the -Ounchecked flag reference.
My original argument about failing for no discernible reason still stands. 
precondition is a thought out check for a failing state. member lookup failures 
are going to be because things don’t exist for which you presumably expected to 
exist.___
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

[Joe DeCapo via swift-evolution]

> On Dec 7, 2017, at 12:38 AM, Letanyan Arumugam via swift-evolution 
>  wrote:
> 
> My fear is that a design pattern around dynamic members and calls arise that 
> is used to bypass the perceived initial annoyance of Swifts type system from 
> new developers that come over to Swift and are now starting to try and go 
> native. They have no reason to think about their conforming types as 
> something that might fail because they’re using it to model behaviour that 
> they’re used to (good or bad). I don’t see why it’s so bad to remind people 
> that these conformances should be failing and only in rare cases should you 
> ever have a dynamic member lookup that is fine to ignore all failing lookups.
> 
> People coming from JavaScript could perceivably make dictionaries conform. 
> And later JSON, database, file and basically all resource API’s would follow.
> 
> Why would all of this happen rather than people behaving the way current 
> Swift community members behave?
> Because I worry that by bringing in people from other languages that a new 
> learning path is created. One where you start by learning your language 
> interoperating with Swift. And then pick up other Swift features as you go 
> along using your Python API for example. This would create a disparate Swift 
> community.

When I began writing Python, I initially named all my variables in camel case. 
And when I used the Subprocess module, I was passing return codes throughout my 
code base like it was bash. Even though I didn't know what was idiomatic in 
Python at that time, I could still sense a code smell in what I was writing. I 
soon learned that snake case was the standard, so I updated my code. And 
eventually I learned how to use exceptions and I refactored my code to use them 
instead of return codes. I doubt that this is unusual when coming to a new 
language with previous experience in other languages. It seems inevitable, and 
a normal process for becoming familiar with the idioms of a certain language 
community. I don't think we need to be so fearful of the community fracturing 
if people from a dynamic language background come to Swift and initially use 
those idioms. It will always be more burdensome to do things in a non-idiomatic 
way, and over time people will learn how to write idiomatic Swift.

Also, since this is an expert-level feature, I highly doubt that newcomers to 
Swift will be writing their own types that adopt the DynamicMemberLookup or 
DynamicCallable protocols. They'll simply be using existing bridges to the 
dynamic language they want to interact with. And if expert Swift users find a 
legitimate use case for this beyond dynamic language interop, I don't think 
that's necessarily a bad thing if it helps them solve their problem.

___
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

[Letanyan Arumugam via swift-evolution]

Regards

Letanyan Arumugam



> On 07 Dec 2017, at 17:34, Gwendal Roué  wrote:
> 
>> 
>> Le 7 déc. 2017 à 16:15, Letanyan Arumugam via swift-evolution 
>> > a écrit :
>> 
>> 
>> 
>>> On 07 Dec 2017, at 17:02, Xiaodi Wu >> > wrote:
>>> 
>>> 
>>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>>> > wrote:
>>> 
 This seems marginally tolerable, but excessive.
 
 Do we mark every usage of a type that can generate precondition failures 
 or fatal errors for reasons other than “no such method?” No, we don’t.
 
>>> 
>>> fatalError shouldn’t be used excessively. API surface areas for these types 
>>> are going to be massive (infinite technically). I assume many people are 
>>> going to be writing a lot of code would these types and calling many 
>>> methods and properties which would all essentially have a fatalError. Would 
>>> you consider it good code if the majority of all your types had methods 
>>> defined with fatalError calls.
>>> 
>>> What is the basis for this claim? Probably the majority of standard library 
>>> methods check preconditions and trap on failure. That is how I write my 
>>> code as well.
>>> 
>> 
>> I’m talking specifically about fatalError not precondition. fatalError is 
>> something that goes out with production code while precondition is used for 
>> debugging. I think you would agree a shipped program that has many states of 
>> being unrecoverable is not a good design?
> 
> When a question is framed so that there is only one possible answer, the 
> question is flawed.
> 
> The question is not whether one likes dynamism or not (the answer is pretty 
> obvious for many people here, and we don't learn much).

One might call that a rhetorical question :) Which is probably not appropriate 
here so I apologies for that.

> 
> It isn't if one would use the discussed features if the proposals were 
> accepted (many here would swear they wouldn't, even if many of them will lick 
> those dynamic features like candy, whenever appropriate, as every sane person 
> would).
> 
I’m not sure anyone here ever said they wouldn’t use it. There’s just a concern 
about how much it would be used.


> Currently, it's a static vs. dynamic debate. But we should talk about a 
> precise proposal, and a good one after that, which comes with plenty of 
> information, and even playgrounds to look at!
> 

I’m not taking sides on which is better (each to their own use cases). I am 
talking about the proposals current design. The current design says that 
dynamic and static calls are on equal footing. This implies to the programmer 
that either way of doing things is correct. A programmer from a dynamic 
environment is usually going to choose the dynamic way because it’s more 
powerful and easier to use. I just merely want the design to have a way of 
showing the programmer that they should think twice about using it in an 
implicitly failing way. Whether that be renaming the protocol to something like 
UnsafeDynamicMemberLookup or something else along the lines of what Swift 
currently does.



___
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

[Goffredo Marocchi via swift-evolution]

Well, mocking was effective and super easy to do proper unit testing with... 
that must count as a disaster or something ;).

Sent from my iPhone

> On 7 Dec 2017, at 15:32, C. Keith Ray via swift-evolution 
>  wrote:
> 
> Let's see what disasters were created by people abusing NSProxy, the ObjC 
> moral equivalent of a dynamic member lookup type.
> 
> I'm not aware of anything.
> 
> --
> C. Keith Ray
> 
> * https://leanpub.com/wepntk <- buy my book?
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
> * http://agilesolutionspace.blogspot.com/
> 
>> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On 07 Dec 2017, at 17:02, Xiaodi Wu  wrote:
>>> 
>>> 
 On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
  wrote:
 
> This seems marginally tolerable, but excessive.
> 
> Do we mark every usage of a type that can generate precondition failures 
> or fatal errors for reasons other than “no such method?” No, we don’t.
> 
 
 fatalError shouldn’t be used excessively. API surface areas for these 
 types are going to be massive (infinite technically). I assume many people 
 are going to be writing a lot of code would these types and calling many 
 methods and properties which would all essentially have a fatalError. 
 Would you consider it good code if the majority of all your types had 
 methods defined with fatalError calls.
>>> 
>>> What is the basis for this claim? Probably the majority of standard library 
>>> methods check preconditions and trap on failure. That is how I write my 
>>> code as well.
 
>> 
>> I’m talking specifically about fatalError not precondition. fatalError is 
>> something that goes out with production code while precondition is used for 
>> debugging. I think you would agree a shipped program that has many states of 
>> being unrecoverable is not a good design?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam  wrote:

>
>
> On 07 Dec 2017, at 17:02, Xiaodi Wu  wrote:
>
>
> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> This seems marginally tolerable, but excessive.
>>
>> Do we mark every usage of a type that can generate precondition failures
>> or fatal errors for reasons other than “no such method?” No, we don’t.
>>
>> fatalError shouldn’t be used excessively. API surface areas for these
>> types are going to be massive (infinite technically). I assume many people
>> are going to be writing a lot of code would these types and calling many
>> methods and properties which would all essentially have a fatalError. Would
>> you consider it good code if the majority of all your types had methods
>> defined with fatalError calls.
>>
>
> What is the basis for this claim? Probably the majority of standard
> library methods check preconditions and trap on failure. That is how I
> write my code as well.
>
>>
>>
> I’m talking specifically about fatalError not precondition. fatalError is
> something that goes out with production code while precondition is used for
> debugging. I think you would agree a shipped program that has many states
> of being unrecoverable is not a good design?
>

Precondition checks are active in release code. When a program encounters
conditions that have no obvious recovery, trapping immediately is the only
safe option; this is what Swift means by “safety” and the practice is
encouraged.

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

[Gwendal Roué via swift-evolution]

> Le 7 déc. 2017 à 16:33, C. Keith Ray via swift-evolution 
>  a écrit :
> 
> Let's see what disasters were created by people abusing NSProxy, the ObjC 
> moral equivalent of a dynamic member lookup type.
> 
> I'm not aware of anything.


I'm sure you are ;-)

I'm not expert at all of early ObjC... But wasn't NSProxy the base of 
good-old-times RPC?

OK, in 2017 we know that RPC is dangerous. For example, when `() -> Int` relies 
on a network call, it's almost impossible to handle errors.

But still, is it because an API can be used for bad things that an API is bad?

Gwendal

___
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

[Gwendal Roué via swift-evolution]

> Le 7 déc. 2017 à 16:15, Letanyan Arumugam via swift-evolution 
>  a écrit :
> 
> 
> 
>> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote:
>> 
>> 
>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>> > wrote:
>> 
>>> This seems marginally tolerable, but excessive.
>>> 
>>> Do we mark every usage of a type that can generate precondition failures or 
>>> fatal errors for reasons other than “no such method?” No, we don’t.
>>> 
>> 
>> fatalError shouldn’t be used excessively. API surface areas for these types 
>> are going to be massive (infinite technically). I assume many people are 
>> going to be writing a lot of code would these types and calling many methods 
>> and properties which would all essentially have a fatalError. Would you 
>> consider it good code if the majority of all your types had methods defined 
>> with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard library 
>> methods check preconditions and trap on failure. That is how I write my code 
>> as well.
>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is 
> something that goes out with production code while precondition is used for 
> debugging. I think you would agree a shipped program that has many states of 
> being unrecoverable is not a good design?

When a question is framed so that there is only one possible answer, the 
question is flawed.

The question is not whether one likes dynamism or not (the answer is pretty 
obvious for many people here, and we don't learn much).

It isn't if one would use the discussed features if the proposals were accepted 
(many here would swear they wouldn't, even if many of them will lick those 
dynamic features like candy, whenever appropriate, as every sane person would).

Currently, it's a static vs. dynamic debate. But we should talk about a precise 
proposal, and a good one after that, which comes with plenty of information, 
and even playgrounds to look at!

Gwendal

___
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

[C. Keith Ray via swift-evolution]

Let's see what disasters were created by people abusing NSProxy, the ObjC moral 
equivalent of a dynamic member lookup type.

I'm not aware of anything.

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution 
>  wrote:
> 
> 
> 
>> On 07 Dec 2017, at 17:02, Xiaodi Wu  wrote:
>> 
>> 
>>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>>>  wrote:
>>> 
 This seems marginally tolerable, but excessive.
 
 Do we mark every usage of a type that can generate precondition failures 
 or fatal errors for reasons other than “no such method?” No, we don’t.
 
>>> 
>>> fatalError shouldn’t be used excessively. API surface areas for these types 
>>> are going to be massive (infinite technically). I assume many people are 
>>> going to be writing a lot of code would these types and calling many 
>>> methods and properties which would all essentially have a fatalError. Would 
>>> you consider it good code if the majority of all your types had methods 
>>> defined with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard library 
>> methods check preconditions and trap on failure. That is how I write my code 
>> as well.
>>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is 
> something that goes out with production code while precondition is used for 
> debugging. I think you would agree a shipped program that has many states of 
> being unrecoverable is not a good design?
> ___
> 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

[Letanyan Arumugam via swift-evolution]

> On 07 Dec 2017, at 17:02, Xiaodi Wu  wrote:
> 
> 
> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
> > wrote:
> 
>> This seems marginally tolerable, but excessive.
>> 
>> Do we mark every usage of a type that can generate precondition failures or 
>> fatal errors for reasons other than “no such method?” No, we don’t.
>> 
> 
> fatalError shouldn’t be used excessively. API surface areas for these types 
> are going to be massive (infinite technically). I assume many people are 
> going to be writing a lot of code would these types and calling many methods 
> and properties which would all essentially have a fatalError. Would you 
> consider it good code if the majority of all your types had methods defined 
> with fatalError calls.
> 
> What is the basis for this claim? Probably the majority of standard library 
> methods check preconditions and trap on failure. That is how I write my code 
> as well.
> 

I’m talking specifically about fatalError not precondition. fatalError is 
something that goes out with production code while precondition is used for 
debugging. I think you would agree a shipped program that has many states of 
being unrecoverable is not a good design?___
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

[Xiaodi Wu via swift-evolution]

On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <
swift-evolution@swift.org> wrote:

>
> This seems marginally tolerable, but excessive.
>
> Do we mark every usage of a type that can generate precondition failures
> or fatal errors for reasons other than “no such method?” No, we don’t.
>
> fatalError shouldn’t be used excessively. API surface areas for these
> types are going to be massive (infinite technically). I assume many people
> are going to be writing a lot of code would these types and calling many
> methods and properties which would all essentially have a fatalError. Would
> you consider it good code if the majority of all your types had methods
> defined with fatalError calls.
>

What is the basis for this claim? Probably the majority of standard library
methods check preconditions and trap on failure. That is how I write my
code as well.

What’s so wrong with adding another layer of protection on top to bypass if
> you want to do this.
>
> Do we use a syntactically privileged marker instead of just using words
> like “unsafe” for types that expose direct access to raw memory? No, we
> don’t.
>
> Okay we use Unsafe. Then should we have something similar for this. A
> UncheckedDynamicMemberLookup [1] and a DynamicMemberLookup [2]? my one
> objection to this would be that I would like to convert a
> UncheckedDynamicMemberLookup to a DynamicMemberLookup.
>
> [1] would work like the current proposal for DynamicMemberLookup
> [2] would only allow returning an optional
>
>
> My main objection to the critical responses is that most of the objections
> are fundamentally cultural, not technical, and are fear-based, not
> evidence-based.
>
>
> The goal of this proposal is to bring people from a culture where
> excessive use of this would be the norm for them. Why would it be so hard
> to imagine that people would adopt bad principles, knowing or unknowing,
> because this is what they’ve always done?
>
> Evidence is going to be hard to get since I don’t know any other language
> like Swift that has done this for the same reasons before. As far as C#
> goes were they trying to get people from a heavily based dynamic community
> or help those already in the community?
>
>
> If a little extra language ceremony helps assuage those fears, I guess I’d
> consider it. I still think static analysis — starting and mostly ending
> with boring old syntax coloring — answers most all the concerns people have
> raised, and this debate is a tempest in a teapot.
>
>
> I'm unsure of this, but as far as I’m aware Swift language proposals
> shouldn’t rely on editor features. But like I said I’m unsure of this and
> if someone could clarify this that would great.
>
>
> ___
> 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

[Vincent Esche via swift-evolution]

On Wed, Dec 6, 2017 at 6:14 PM, Chris Lattner  wrote:

> On Dec 6, 2017, at 5:41 AM, Vincent Esche via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Alas while Swift's generics provide a nice basic foundation, they still
> have big gaps in what can be expressed through them.
> > And i'm not talking about HKT or any such more advanced use of types).
> I'm talking about the basic stuff. Generic abstractions over type
> conversion. Generic abstractions over arithmetic operators. This kind of
> stuff. Stuff, that ironically would be necessary for a generic yet
> idiomatic implementation of Linear Algebra algorithms in Swift.
>
> This is all orthogonal to the proposal.  I’m certainly not opposed to the
> generics system getting better :-), […]
>

Exactly. That’s my whole point. How do we make sure these are understood to
be orthogonal? We’re talking about the average Joe here.
For someone used to stringly-typed dictionaries (Python e.g.) and
stringly-typed reflection (many message-passing/dynamic languages) it will
not be clear that 9/10 times dynamic stringly-typed member lookup is not
the right tool of choice for modeling type relations in a statically typed
language, which is exactly how these things are done in many scripting
languages.

> And I think that we have more urgent topics at hand that need to get
> fixed.
> > Swift's generics are very limited. We hardly have any tooling.
> > Diagnostics are just shy of migrating from "utter garbage" to "getting
> usable", by modern standards.
> > Integration with Xcode still to this day is an utter clusterfuck. With
> errors pointing to the void, regularly.
> > I'd prefer the team to focus on these, solidifying the foundation and
> once that's done
> > and the result have been proven to be sound by time I'd love to see
> Swift get some more dynamism.
>
> I’m not disagreeing with your point about other things needing to be
> improved, but the only question is whether this proposal fits with the
> right long term direction for Swift.  It is not a prioritization question.
>

I’m not so much thinking of it as a prioritization issue (as you already
did the implementation and made clear from the beginning that you would do
the heavy lifting, not the core team), but more of a timing issue. It
absolutely is a timing issue from my point of view, for the very reasons
that I gave previously.

A frequent argument against any of the reasonable doubts expressed in this
thread is the notion that the community “would figure something out” and
“prevent any anti-patterns and misuses from gaining a foothold”.

I have doubts about this. There is plenty of evidence for the contrary:

- We don't have a strong unit testing culture in the swift community.
Hardly any Swift project on Github has proper unit test coverage. Most have
none at all.
  And I can’t blame them/us, as XCTest is more of a burden to use than a
help. XCTest on Linux is even worse if not border-line offensive to work
with.
- We don't have a strong culture of “avoid IUOs at all costs” either. I see
them all over the place when going through random Github projects.
  They are everywhere. I would give you numbers, but “!” is kinda hard to
search for (i.e. impossible) using Github’s source code search feature.
- There is still plenty of use of AnyObject and its cousins where for a
long time we have had better solutions.
- There is still incredible amounts of non-typesafe APIs (and I’m talking
about fresh 3rd-party stuff here, not legacy frameworks).
- …

> At this point in time it's like opening Pandora's box.
>
> I, still, have yet to see any evidence of harm that this proposal can
> cause.
>

The harm from my perspective is not so much of technical nature than more
of a cultural one.
And plenty of “evidence” has been provided in this thread for why this
proposal is a risk for the language.

If not then Letanyan put it perfectly:

On Thu, Dec 7, 2017 at 7:37 AM, Letanyan Arumugam via swift-evolution <
swift-evolution@swift.org> wrote:

> My main objection to the critical responses is that most of the objections
> are fundamentally cultural, not technical, and are fear-based, not
> evidence-based.
>
>
> The goal of this proposal is to *bring people from a culture where
> excessive use of this would be the norm for them*. *Why would it be so
> hard to imagine that people would adopt bad principles, knowing or
> unknowing, because this is what they’ve always done?*
>

> Evidence is going to be hard to get since I don’t know any other language
> like Swift that has done this for the same reasons before. As far as C#
> goes were they trying to get people from a heavily based dynamic community
> or help those already in the community?
>

[…]


My fear is that a design pattern around dynamic members and calls arise
> that is *used to bypass the perceived initial annoyance of Swifts type
> system from new developers that come over to Swift* and are now starting
> to try and go native. They *have 

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

[Gwendal Roué via swift-evolution]

> Le 7 déc. 2017 à 13:59, Benjamin G  a écrit :
> 
> 
> 
> On Thu, Dec 7, 2017 at 1:45 PM, Gwendal Roué  > wrote:
> 
>> Le 7 déc. 2017 à 11:00, Benjamin G via swift-evolution 
>> > a écrit :
>> 
>> Until, and if, the “resistance” presents some conceptual explanation of how 
>> this could cause harm (I’m not asking for anything concrete, just a logical 
>> series of events that causes a plausible problem in practice), my belief is 
>> that the Swift community will see this as unwarranted fear.
>> 
>> On the server side : 
>> automatically generate an administration api for your model based on 
>> introspection. Since swift doesn't provide anything convenient, and people 
>> may simply try to "port" approach from python framework (like django), 
>> they'll resort on recreating some kind of BaseDynamicObject that you'll have 
>> to extend for all your base classe, using some "properties()" and 
>> "methods()" functions to define your properties and methods for your model.
>> 
>> Or :
>> Automatically generate a database schema based on your model. Same idea.
> 
> The explicit harm that Chris is looking for is yet to be shown. 
> 
> The harm isn't in generating the database schema, or the administration api. 
> it's in abandonning all kind of compile-time safety in your model layer (and 
> such by extension in almost every part of your stack) in order to accomplish 
> this. Dynamic language obviously don't have this concern, but thankfully 
> Swift isn't a dynamic language.

Yes, yes, but this has been said dozens of time already in this thread. Chris's 
question is *how*, not *what*. It's much harder to answer, I agree.

>>  You should not assume that everybody feels an horror thrill by reading such 
>> applications of dynamism. As a matter of fact, users of dynamic languages 
>> *live* and *enjoy* this. Python and Ruby users, obviously (Rails + Django), 
>> but also ours close cousins, the Objective-C developers, who rely on 
>> Key-Value coding or validation methods. Those use cases are, I'm sorry to 
>> say it, *compelling* use cases for dynamism.
> 
> 
> Not sure what field you're working in, but at least on the server the general 
> trend toward more compile-time safety has been pretty obvious for some time 
> now.

I'm not sure you really care about my answer.

Gwendal

___
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

[Benjamin G via swift-evolution]

On Thu, Dec 7, 2017 at 1:45 PM, Gwendal Roué  wrote:

>
> Le 7 déc. 2017 à 11:00, Benjamin G via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Until, and if, the “resistance” presents some conceptual explanation of
>> how this could cause harm (I’m not asking for anything concrete, just a
>> logical series of events that causes a plausible problem in practice), my
>> belief is that the Swift community will see this as unwarranted fear.
>>
>
> On the server side :
> automatically generate an administration api for your model based on
> introspection. Since swift doesn't provide anything convenient, and people
> may simply try to "port" approach from python framework (like django),
> they'll resort on recreating some kind of BaseDynamicObject that you'll
> have to extend for all your base classe, using some "properties()" and
> "methods()" functions to define your properties and methods for your model.
>
> Or :
> Automatically generate a database schema based on your model. Same idea.
>
>
> The explicit harm that Chris is looking for is yet to be shown.
>

The harm isn't in generating the database schema, or the administration
api. it's in abandonning all kind of compile-time safety in your model
layer (and such by extension in almost every part of your stack) in order
to accomplish this. Dynamic language obviously don't have this concern, but
thankfully Swift isn't a dynamic language.


>
> You should not assume that everybody feels an horror thrill by reading
> such applications of dynamism. As a matter of fact, users of dynamic
> languages *live* and *enjoy* this. Python and Ruby users, obviously (Rails
> + Django), but also ours close cousins, the Objective-C developers, who
> rely on Key-Value coding or validation methods. Those use cases are, I'm
> sorry to say it, *compelling* use cases for dynamism.
>

Not sure what field you're working in, but at least on the server the
general trend toward more compile-time safety has been pretty obvious for
some time now.


>
> Ironically, "Explicit is better than implicit" is a... Python motto ;-)
>

It's also a community that used to rely on writing types annotation and
signatures in comments above functions as a best practice, before
annotations became a thing. Not sure we should take it as an example.


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

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

[David James via swift-evolution]

+1

It would be nice to have generic supertype constraints, with syntax along the 
lines of `where A:B`. 

Not sure if this is the same as what’s being suggested.

Example:
struct ViewWrapper {
let views:[T]
func add(_ view:V) -> ViewWrapper where V:T { // V must be a 
subtype of T
let newViews = views + [view] // pseudo code
return ViewWrapper(views: newViews)
}
}
let controls  = ViewWrapper(views:[])
controls.add(UIButton()) // succeeds, UIButton is a UIControl
controls.add(UIView()) // fails, UIView is not a UIControl
David

> On 6 Dec 2017, at 00:34, Rex Fenley via swift-evolution 
>  wrote:
> 
> Huge +1, I've asked for this in the past too.
> 
> Have you also found this limitation frustrating? 
>   - Yes
> 
> In what contexts?
>   - APIs that have this requirement and end up enforcing them through runtime 
> type checking and throws. Shows up in some network data mapping code I have 
> that generalizes over Core Data and Realm (and other databases). The protocol 
> implementer must specify the subtype for the raw mapping of JSON and base 
> type for the DB reading/writing layer. Could see this showing up whenever 
> there's a separation of concerns between what business logic belongs to the 
> base type and subtypes of a more generalized system. I could potentially see 
> the same issue showing up in code generalizing the mapping of data to UI, 
> like UITableView/UITableViewCell.
> 
> Does anyone have reservations about introducing this capability?
>   - I do not
>> 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 
>> 
> -- 
> Rex Fenley  |  IOS DEVELOPER
> 
> 
> Remind.com  |  BLOG   |  
> FOLLOW US   |  LIKE US 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

David James

___
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

[Benjamin G via swift-evolution]

On Thu, Dec 7, 2017 at 6:41 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 6, 2017, at 8:11 PM, Joe DeCapo via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Has all of this ruined the language thus far? No. Because the Swift core
> team doesn’t design, and the Swift community doesn’t adopt, ill-designed
> APIs that turn these facts into problems.
>
>
> Yeah, I think I'd prefer this to stay as a normal protocol conformance.
> But if the proportion of resistance is high enough,…
>
>
> Until, and if, the “resistance” presents some conceptual explanation of
> how this could cause harm (I’m not asking for anything concrete, just a
> logical series of events that causes a plausible problem in practice), my
> belief is that the Swift community will see this as unwarranted fear.
>

On the server side :
automatically generate an administration api for your model based on
introspection. Since swift doesn't provide anything convenient, and people
may simply try to "port" approach from python framework (like django),
they'll resort on recreating some kind of BaseDynamicObject that you'll
have to extend for all your base classe, using some "properties()" and
"methods()" functions to define your properties and methods for your model.

Or :
Automatically generate a database schema based on your model. Same idea.





>
> This is particularly true given that the proposal is completely consistent
> with previous design decisions in Swift, decisions which have served us
> well.
>
> -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