Re: [swift-evolution] A case for postponing ABI stability

[Freak Show via swift-evolution]

I have to assume that was sarcasm.

The Release to Release Binary Compatibility with SOM 
(http://hobbes.nmsu.edu/h-viewer.php?dir=/pub/os2/doc=R2R_SOM.zip) paper 
includes the following footnote:

"We exclude Microsoft’s COM [14] because it is an interface model, not an 
object model and it’s ABI forbids subclassing between library and application. 
If our analysis technique is applied to COM, one sees that it supports only 
Transformations 0 to 4, which places it in the category of procedural pro- 
gramming rather than object-oriented programming. "

> On Jan 28, 2017, at 23:18, Russ Bishop  wrote:
> 
> Yeah and Microsoft’s COM is a reasonable approach

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

Re: [swift-evolution] Optional Assignment Operator

[Freak Show via swift-evolution]

I'm just gonna weigh in with

1) I don't like optionals, I find them intrusive and prefer Objective C's 
message eating nil but whatever.  I've shipped code in C, C++, and Java where 
dereferencing or messaging nil/null is "A Bad Thing (tm)" and its not really a 
driving issue in my coding or design.

2) I REALLY dislike operators.  A lot.  Like - they're punctuation, man.  I can 
barely fathom the default set.  They don't "say" anything to me as I read the 
code - they're syntactic noise.

I *much* prefer meaningful method names.  

if let airportName = airports["DUB"] {
print("The name of the airport is \(airportName).")
} else {
print("That airport is not in the airports dictionary.")
}

vs (sorry, mixing languages)

airportName := airports at: #DUB ifAbsent: [ "unknown" ]
print("The name of the airport is \(airportName)")

One of these I can read, even as a lay person, and understand.  The other is 
cartoon character cursing.

> On Jan 25, 2017, at 11:39, John McCall via swift-evolution 
>  wrote:
> 
>> On Jan 25, 2017, at 2:37 PM, Jacob Bandes-Storch > > wrote:
>> If no uses are found (which I suspect will be the case), it becomes hard to 
>> also find evidence of harm other than in contrived scenarios. Perhaps 
>> contrived will be all we can find.
> 
> Well, if there's no harm, having a weird corner case that doesn't hurt 
> anybody is fine.  I certainly suspect that there are use cases for using a 
> non-simple assignment operator there, so calling out = as a special case is a 
> bit weird.
> 
> John.
> 
>> Anyway, this is a bit off-topic for this thread...
>> On Wed, Jan 25, 2017 at 11:24 AM John McCall > > wrote:
>>> On Jan 25, 2017, at 1:48 PM, Xiaodi Wu >> > wrote:
>>> Given lack of evidence of harm, is it really important to make such a 
>>> source-breaking change?
>> 
>> My first instinct is that, no, it's not important.  However, we haven't 
>> actually *tried* to find any evidence of harm, so it's a bit conclusory.  If 
>> someone wants to make an evidence-based argument that it's harmful and that 
>> almost nobody is using it (intentionally/correctly), the balance could swing 
>> the other way.  That's for someone else to prove, though, since yes, at this 
>> point the bias has to be towards leaving things be.
>> 
>> John.
>> 
>>> 
>>> On Wed, Jan 25, 2017 at 12:45 John McCall via swift-evolution 
>>> > wrote:
 On Jan 25, 2017, at 1:35 PM, Jacob Bandes-Storch > wrote:
 
 Agreed, IMO it would be quite dangerous for "a ??= b" to mean anything 
 other than "a = a ?? b".
 
 On another note, I don't see the value of "a? = b". I had never realized 
 before that this works. Is this feature actually used in the wild? Should 
 we consider removing it? (I could perhaps see some value if the assignment 
 operator were overloadable, but it's not.)
>>> 
>>> The core semantics (that ? on an l-value still produces an l-value) fall 
>>> out from the ability to call a mutating method with a?.foo().  Once you 
>>> have that, you have to decide what it means to put such an l-value to the 
>>> left of an assignment operator, and we decided to make it Just Work™.  I 
>>> agree that it is not a particularly useful operation in idiomatic Swift, 
>>> especially with simple assignment (=), and we could consider just 
>>> disallowing it.
>>> 
>>> It also comes up with optional properties, I think, which is something we 
>>> weren't always certain we were going to ban in native Swift (as opposed to 
>>> imported ObjC code, where they're a fact of life).
>>> 
>>> John.
>>> 
 
 Jacob
 
 On Wed, Jan 25, 2017 at 10:28 AM, John McCall > wrote:
> On Jan 25, 2017, at 12:47 PM, Jacob Bandes-Storch via swift-evolution 
> > wrote:
> Really? My observation from a quick test is that "a? = b" assigns b to a 
> if a already has a value, or does nothing if it's nil. This is sort of 
> the opposite of what's being proposed, which is that "a ?= b" should 
> assign to a only if it does NOT have a value.
 
 Right.  On the other hand, this does seem like a poor spelling for the 
 operator, given the ease of confusion.
 
 Also, I'm finding it hard to imagine a use for this where the equivalent 
 ?? invocation wouldn't be *much* clearer.  It just feels like you must be 
 doing something backwards — "I've filled in a default value for this 
 variable, now overwrite it if this other value exists".  Wouldn't the 
 reverse generally be better?
 
 John.
 
> On Wed, Jan 25, 2017 at 9:33 AM Joe Groff via 

Re: [swift-evolution] A case for postponing ABI stability

[Freak Show via swift-evolution]

Maybe so - but IBM solved this very problem along with release to release 
binary compatibility for C++ and a number of other languages twenty years ago 
with the System Object Model (SOM).

I'm not arguing for its adoption per se - but good ideas are always worth 
stealing and there was some solid engineering in there.

Sent from the road

> On Jan 27, 2017, at 09:19, Tino Heth via swift-evolution 
>  wrote:
> 
> I wouldn't expect that I can mix language and framework versions freely.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] A case for postponing ABI stability

[Freak Show via swift-evolution]

This is both great to hear (ivar introspection available) and a little 
disappointing (method level not).  Basically, I would hope for at least enough 
to allow implementation of KVC - which would require the ability to find and 
invoke methods by name.



> On Jan 24, 2017, at 14:16, Joe Groff  wrote:
> 
> a lot of the information you'd need for many dynamic features is already 
> there, and planned to be stabilized as part of the ABI. We already emit 
> reflection data that describes the physical layouts of types, and once those 
> formats are stabilized, building a library that interprets the metadata is 
> additive (and could conceivably be done by a third party independent of the 
> standard library). There may not be metadata for individual methods yet

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

Re: [swift-evolution] A case for postponing ABI stability

[Freak Show via swift-evolution]

I do not see how you can consider standardizing ABI without first standardizing 
the dynamic features and the desired programmatic interfaces to them.  

We know that dynamic features need to come.  They will impact everything.  My 
personal ideal is a language that smoothly transitions from fully dynamic to 
fully static without a lot of fuss. 



> On Jan 24, 2017, at 11:45, Rahul Malik via swift-evolution 
>  wrote:
> 
> I agree that we shouldn't rush decisions but I feel like the emphasis of ABI 
> stability has been a factor in discussing a number of proposals for Swift 4 
> and has been a core goal of this next major release. Seems strange to 
> deemphasize it and its importance at this time.
> 
> Below are some thoughts from my perspective as someone involved in the 
> decision to adopt Swift in production at work.
> 
> ABI Stability
> The reality is that stability in the ABI is important for a number of 
> developers and companies considering adopting or that have already adopted 
> Swift. Shipping the runtime increases the binary size of every app that ships 
> with it and becomes a barrier in user acquisition due to the increased app 
> size. If I'm not mistaken this issue multiplies as you add extensions to your 
> application since they all bundle the runtime separately. Due to these 
> issues, ABI Stability is one of the leading reasons we have not adopted Swift 
> in our flagship app.
> 
> API Stability
> This I would consider just as important as the ABI stability. Changing APIs 
> provides a lot of churn on developers that manage large codebases and I've 
> often heard of issues using the Swift migrator at scale which doesn't help. 
> I'd like to see a less drastic approach like Jonathan is suggesting where we 
> have clear indication of APIs that might change or at least allowing one 
> minor release where an API will warn if it's used but is still available to 
> allow developers time to migrate.
> 
> Right now I think it's important to keep ABI stability as a core tenant of 
> any proposal and acknowledge that we need to just flag how proposals will 
> affect ABI stability. This seems inline with our stance on the development of 
> a Rust-inspired `Memory Ownership Model`: "While a full memory ownership 
> model is likely too large for Swift 4 stage 1, we need a comprehensive design 
> to understand how it will change the ABI."
> 
> On Tue, Jan 24, 2017 at 3:16 AM, Georgios Moschovitis via swift-evolution 
> > wrote:
> > I'm not really sure if the String-changes affect the ABI, but none the 
> > less, I strongly agree with your opinion that things shouldn't be done in a 
> > hurry, and I hope that Swift keeps the courage to break things for the 
> > better (sporadically ;-)
> 
> +1
> 
> ___
> 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] Reduce with inout

[Freak Show via swift-evolution]

Am I the only one who finds this incredibly ugly and hard to read?

This is more or less solved by inject:into: idiom.  There is no reason for 
inout for this particular problem.


> On Jan 24, 2017, at 06:43, Gwendal Roué via swift-evolution 
>  wrote:
> 
> But what if we stop fighting? Isn't the following code the correct version of 
> Chris's vision ?
> 
> extension Sequence {
> func reduce(mutating result: inout A, _ combine: (inout A, 
> Iterator.Element) -> ()) {
> for element in self {
> combine(, element)
> }
> }
> }
> 
> extension Sequence where Iterator.Element: Equatable {
> func uniq() -> [Iterator.Element] {
> var result: [Iterator.Element] = [] // meh
> reduce(mutating: ) { (result: inout [Iterator.Element], 
> element) in
> if result.last != element {
> result.append(element)
> }
> }
> return result
> }
> }
> 
> let x = [1, 1, 2, 3]
> x.uniq() // [1, 2, 3]

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

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Freak Show via swift-evolution]

I am almost not sure if this is a joke or not.  That is an incredibly 
complicated looking hieroglyphic to dispatch a bit of code.  I do this:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
NSString* message = [NSString stringWithFormat: 
@"prepareSeque%@To%@:",(segue.identifier ? segue.identifier : @""), 
[segue.destinationViewController class]];
SEL method = NSSelectorFromString(message);
if([self respondsToSelector:method])
{
[self performSelector:method 
withObject:segue.destinationViewController];
}
}
// Assume segue identifier was NextStep and we are going to a NextViewController
-(void)prepareSequeNextStepToNextViewController:(NextViewController*)vc
{
// do specific work in a small focused method instead of buried in a giant 
ugly switch statement
}

Burying all that logic in a bunch of control statements just obfuscates intent. 
 Now, you may argue my prepareForSegue is a little bit ugly and I would agree 
with you - but I write that once, stick it on UIViewController as an extension 
method, and never look at it again, instead going off the naming convention - 
much like the responder chain works.

I keep hearing the same justifications over and over.  "Compiler can't check 
that", "pattern matching", "powerful enums", "protection from nil", "faster 
execution", "exhaustively checked switch statements" etc I do not value any 
of that stuff and it all goes out the window once your program beings consuming 
data from outside.  It doesn't make my programs more powerful, more expressive, 
more robust, or better.  It does slow me down a lot trying to satisfy a bunch 
of constraints that are, frankly, irrelevant to my problem domain and what it 
does instead is refocus my attention from the problem domain into the 
implementation domain unnecessarily.

The conventional wisdom is that switch statements are an anti pattern in the 
presence of OO features.  They're brittle and basically they're goto's.  
Polymorphism is to be preferred. I thought we settled that in the 90s.

It is becoming more and more clear that the ideals of Swift are nothing like 
the Smalltalk ideals that gave us Cocoa (and Cocoa is a very elegant framework 
loaded with beautiful design patterns that have served us very well - well 
enough to let little Apple eat Microsoft's lunch).  Swift is a lot closer to 
the ideals of C++ and ML and they are a terrible fit on top of a Smalltalk 
inspired framework.  Write Swift if you must - but stop screwing up the Apple 
app scene with it.

Seriously, I'm out.  I'd just like to ask the Apple people to stop dumping 
cruft into the Objective C header files.  I don't care about nullable 
annotations or the fake generics cruft.  Objective C is based on Smalltalk.  
This direction is anathema to the Smalltalk ideals that underly the existing 
Cocoa system.  Nils don't matter and generics are nonsense in a dynamically 
typed world.  I mean, have any of you even used a book on Smalltalk as a 
doorstop much less read one?

Basically, you're killing the golden goose.  Like when WebObjects was ported to 
Java.  It didn't survive the change from dynamic language to more rigid type 
constrained Java language.  It just died.

Cocoa won't either.

I'm signing off this list. Swift is about the opposite of what I need in a 
programming language.  It will not scale to the enterprise any better than C++ 
did (clue - it didn't - I was there) and the embedded world has already had 
working Smalltalk implementations all the way down to fpga's 
(http://ieeexplore.ieee.org/document/564744/ 
) for over 20 years so I'm 
completely unpersuaded by the efficiency arguments or the compiler checked 
"correctness" arguments.  Software is never correct, never done, never perfect. 
 Best to have an environment that can deal with that.

Oh and uh - stop pushing Swift as the future.  9/10 jobs doing iOS now demand 
Swift.  Thanks for that.  And by thanks - I mean screw you, Apple.  State of 
iOS development today is a disaster.

Out.

> On Jan 11, 2017, at 00:04, André Videla  wrote:
> 
> func prepareForSegue(segue: UIStoryboardSegue, sender: Any?) {
> Switch (segue.identifier, segue.destination, sender) {
> Case ("Segue"?, let vc as FirstVC, .some(.enumType(let value)) ): // 
> prepare the vc
> ... // other segues
> }
> }

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

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Freak Show via swift-evolution]

Pretty sure Array conforms to hashable and ==.


> On Jan 10, 2017, at 23:43, David Sweeris  wrote:
> 
> 
> On Jan 11, 2017, at 01:29, David Sweeris via swift-evolution 
> > wrote:
> 
>> 
>> On Jan 11, 2017, at 01:11, Freak Show > > wrote:
>> 
>>> 
 On Jan 7, 2017, at 23:37, Derrick Ho > wrote:
 
 I think pattern matching is the most compelling reason to keep tuples.  
 
 If they were gone, how would we replace the following?
 
 switch (a, b) {
 case (value1, value2):
 case (value3, value4):
 }
>>> 
>>> I meant to mention this:  Smalltalk - Objective C's mother language - has 
>>> no switch statement (or 'if' or loops either).  The language is incredibly 
>>> malleable because it only does one thing - send messages to objects and all 
>>> the language constructs are in the library.  It would take very little time 
>>> to add one.  Off and on someone does it as an exercise but it never sticks.
>>> 
>>> Instead, you just use a dictionary of closures.  An Objective C equivalent 
>>> might be:
>>> 
>>> NSDictionary* switch = @{
>>> @[@0,@1]: ^{ NSLog(@"zero one"); }, 
>>> @[@1,@1]: ^{ NSLog(@"one one"); }
>>> };
>>> 
>>> NSArray* pair = @[@3, @5];
>>> 
>>> (switch at:pair ifAbsent:^{})();  //where at:ifAbsent: is added in the 
>>> Smalltalk style as an extension.
>>> 
>>> The Smalltalk equivalent (much less ugly because of the lack of @'s) is
>>> 
>>>  switch := {
>>>   #(0 1)   -> [ Transcript nextPutAll: 'zero one' ] .
>>>   #(1 1)   -> [ Transcript nextPutAll: 'one one' ] . 
>>>   #(1 2) -> [ Transcript nextPutAll: 'one two' ] .
>>> } asDictionary.
>>> 
>>> (switch at: pair ifAbsent:[ [] ]) value.
>>> 
>>> So its not like this is some kind of key feature.  Switch's vs dictionaries 
>>> of closures - pretty much the same thing as pattern matching goes.  The 
>>> only thing you have to do is put an object at key that identifies itself as 
>>> equal to the pattern you will throw at it.
>> 
>> I suspect that's a fair bit slower than a switch  statement. I'm not in 
>> front of my computer, so I can't prove it, though.
> 
> Also, Swift's dictionary requires its keys to conform to `Hashable`, which 
> would mean we'd have to create a formal struct *and* the "==" method for it 
> would have to act as a pattern matched instead of checking equality. I 
> suspect this could break a great many things that depend on "Equatable" 
> meaning what it says.
> 
> - Dave Sweeris (again)

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

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Freak Show via swift-evolution]

> On Jan 7, 2017, at 23:37, Derrick Ho  wrote:
> 
> I think pattern matching is the most compelling reason to keep tuples.  
> 
> If they were gone, how would we replace the following?
> 
> switch (a, b) {
> case (value1, value2):
> case (value3, value4):
> }

I meant to mention this:  Smalltalk - Objective C's mother language - has no 
switch statement (or 'if' or loops either).  The language is incredibly 
malleable because it only does one thing - send messages to objects and all the 
language constructs are in the library.  It would take very little time to add 
one.  Off and on someone does it as an exercise but it never sticks.

Instead, you just use a dictionary of closures.  An Objective C equivalent 
might be:

NSDictionary* switch = @{
@[@0,@1]: ^{ NSLog(@"zero one"); }, 
@[@1,@1]: ^{ NSLog(@"one one"); }
};

NSArray* pair = @[@3, @5];

(switch at:pair ifAbsent:^{})();  //where at:ifAbsent: is added in the 
Smalltalk style as an extension.

The Smalltalk equivalent (much less ugly because of the lack of @'s) is

 switch := {
  #(0 1)   -> [ Transcript nextPutAll: 'zero one' ] .
  #(1 1)   -> [ Transcript nextPutAll: 'one one' ] . 
  #(1 2) -> [ Transcript nextPutAll: 'one two' ] .
} asDictionary.

(switch at: pair ifAbsent:[ [] ]) value.

So its not like this is some kind of key feature.  Switch's vs dictionaries of 
closures - pretty much the same thing as pattern matching goes.  The only thing 
you have to do is put an object at key that identifies itself as equal to the 
pattern you will throw at it.



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

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Freak Show via swift-evolution]

That would be fine.

> On Jan 8, 2017, at 10:31, Micah Hainline  wrote:
> 
> Perhaps we could limit further discussion here to the idea the original 
> poster put forth about eliminating mixed named and unnamed tuple labels.

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

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Freak Show via swift-evolution]

> On Jan 7, 2017, at 22:51, David Sweeris  wrote:

> A really convenient way to pass around multiple values without having to 
> bother with a formal struct.

That's actually a big part of my concern.

The people on this list are, I'm certain, among the top programmers working.

I'm more worried about what happens when average (which IME means barely 
competent) developers get going with this.  I suspect nobody will ever declare 
a struct again.  Type declarations are valuable - they are an opportunity to 
express intent.  OTOH, a pair of ints is a pair of ints and if all pairs of 
ints are type compatible then opportunities for catching errors drop if 
developers start favoring anonymous tuples over former structs.

> On Jan 7, 2017, at 23:37, Derrick Ho  wrote:
> 
> I think pattern matching is the most compelling reason to keep tuples.  
> 
> If they were gone, how would we replace the following?
> 
> switch (a, b) {
> case (value1, value2):
> case (value3, value4):
> }


I really have to ask.  What do you use this for?  In general iPhone application 
programming I have never wanted or needed to do that.  I do some AudioUnits as 
well.  Still never needed it.

Since taking on rescuing a few 2.3 projects on behalf of their highly 
dissatisfied clients (I do this for all languages - not meant to be a Swift 
ding), I have found an astonishing abundance of switch statements that should 
have been handled by subclassing and polymorphism.

The only time I ever find a use for a switch statement is in a parser handling 
wild input.

Regardless, I would extend it to formal structs I think

switch StructName(a, b) {
case (value1, value2):
case (value3, value4):
}

> On Jan 8, 2017, at 05:46, Rod Brown  wrote:
> 
> Apart from your seeming distain for Swift


I tried very hard to keep from expressing anything like that in my proposal.  
Did I fail?  How?

Language designs tend to encourage some behaviors and discourage others.  The 
goal should be to encourage good practices and discourage bad ones.  I am 
basing quite a lot of my opinion on the code being written by other developers 
that I am then asked to come in and work on.  Second generation code.  Is it 
aging well? Why or why not?  Anonymous types everywhere isn't really making 
things safer.  An anonymous pair of ints is an anonymous pair of ints.  You 
might as well return an Array (and adding fixed dimensions as part of the 
immutable array type would solve this just as well).  eg [T][4] or some such 
syntax.  So mostly I'm seeing arguments to keep the syntax because the syntax 
is the syntax because that's what the type is so that is the syntax of the type.

> The following two are collection types you’ve arbitrarily attacked for no 
> reason. There are plenty of examples where each of these makes sense and is 
> relevant within the language:
> 3. Arrays - Lists of items.
> 4. Dictionarys - Key value pair collections.


I did not attack them.  I like them.  I would generally use them instead of 
tuples.  That's how Cocoa largely works now. I used them as comparisons.

> Tuples themselves are actually a major part of how the language is built 
> under the covers, and removing them for no reason is part of taking the guts 
> out of Swift, for no reason.


I don't care what it looks like under the covers.  I am talking about what it 
looks like to the developer.  Seems a bit "Tower of Babel-ish" in some areas.  
The goal was to point that out and see if the language could be simplified.



> On Jan 7, 2017, at 22:51, David Sweeris  wrote:
> 
> 
> 
>> On Jan 7, 2017, at 19:34, Freak Show  wrote:
>> 
>> I think you're missing the forrest for the trees here.'
>> 
>> Let me ask this:  if you remove tuples from the language - what have you 
>> lost - really?  You can still say everything you could before.
> 
> A really convenient way to pass around multiple values without having to 
> bother with a formal struct.
> 
> - Dave Sweeris

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

[swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

[Freak Show via swift-evolution]

FWIW, I searched the previous proposals for any kind of mention of tuple and 
found nothing so forgive me if this has been discussed before.  

Swift currently has 5 ways to represent multi-values.

Classes, structs, arrays, dictionaries, and tuples.

Of these, classes are well established and unique in that they support 
inheritance and often have identity.  

The others, however, are primarily used as value types in their immutable 
incarnations.  Consider a desire to pass around a cartesian coordinate.  The 
following representations are available:

let x = "x"
let y = "y"

struct XY { var x: Int; var y: Int }

var txy = (x: 1, y: 2)   // (.0 1,.1 2)
var sxy = XY(x: 1, y: 2 )// XY
var dxy = [ x: 1, y: 2]  // ["y": 2, "x": 1]
var axy = [ 1, 2 ] // [1,2]
var taxy = ( 1, 2 ) // (.0 1,.1 2)

Their print strings are in the comment to the right - that could be a source of 
a whole other proposal. 

A developer might choose from any one of these to represent a Point.  They all 
represent the same information.  Yet the syntax required to make use of them is 
annoyingly different.

Consider the tuple with named fields which is being used as a sort of anonymous 
ad hoc struct:

txy.x // 1
txy.0 // 1
txy[x] // error
txy[0] // error

vs the declared struct

sxy.x
sxy.0  //error
sxy[x]  //error
sxy[0]  //error

vs the dictionary

dxy.x // error
dxy.0 // error
dxy[x] // 1
dxy[0] // error

and then we have the tuple with unnamed fields

taxy.0 // 1
taxy[0] // error

vs the array
axy.0  // error
axy[0] // 1

It is worth observing that, to the programmer the variable sxy is 
indistinguishable from txy.  They represent the same informtion, they are 
accessed in the exactly the same way.  They are completely equivalent.  However 
this fails:

sxy = txy // error

this succeeds (which may or may not be good depending on context and 
coincidence):

var txy = (x: 1, y: 2)
var txy2 = ( x: 2, y: 3)
txy = txy2 // OK

but this fails (which I think is a good thing)

struct XY { var x: Int; var y: Int }
struct XY2 { var x: Int; var y: Int }

var sxy2 = XY2(x: 2, y: 3)
var sxy = XY(x: 1, y: 2 )

sxy=sxy2 // error

The point of this comparison is to point out that the anonymous type generating 
tuple is a) superfluous and b) a source of confusion and gratuitous complexity. 
 It assumes the role at times of immutable arrays, anonymous structs, and 
immutable dictionaries depending on context and we already have all of those 
things.  

Proposal:

1) Eliminate the tuple as a first level concept.
2) Replace tuples that have named fields with structs or immutable dictionaries.
3) Replace tuples without named fields with immutable arrays.
4) Disallow tuple expressions that mix named and unnamed fields - IOW - this is 
an abomination:

var mixed = (z: 1, 2)

If nothing else in this proposal resonates at all - that should be adopted.

5) Unify field access syntax.  Pick one or allow both on everything (similar to 
javascript).

FWIW, this isn't hard to do already in Objective C.  It is possible to make use 
of default handlers to allow dict.field access on NSDictionary with a very 
small amount of code.  Javascript also supports both dictionary oriented access 
(obj['field']) and dot notation (obj.field) so there is precedent for this kind 
of flexibility.  

6) Unify iteration over all the fields of all the kinds of things that have 
fields.  In this case, tuples are kind of like sequenced collections that have 
been lobotomized.  

Conclusion

There is a lot of overlap among the concepts of structs, immutable 
dictionaries, immutable arrays and tuples.  They are a source of gratuitous 
complexity in the language and a likely ongoing source of frustration as 
developers choose different, equivalent, but incompatible representations for 
common types of data.  My primary fear is that anonymous tuples will tend to 
phase out named struct types and an important source of documentation of intent 
will be lost.

It should also be noted that I am not a compiler or VM writer and I don't give 
a fig how the language does things at the implementation level and this is 
primarily a conceptual/syntactic proposal.  The goal is to make consuming data 
types predictable and simple and eliminate gratuitous complexity at the 
conceptual level through generalization of special cases.

Thanks for reading.  Still reading the process document to figure out how to 
make this "official".




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

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

[Freak Show via swift-evolution]

When you can write CoreData and the rest of Cocoa in pure Swift, you can maybe 
start shoving Objective C to the door.  Until then, a whole community of 
developers still needs to get things done.

As someone very heavily invested in Objective C and is still using it to pay 
the bills, I can say the same WRT Swift.  I don't need nor desire annotating 
everything with nullability specifications - yet now Xcode colors all my code 
yellow demanding I do it.  Nil isn't an error in Objective C  philosophy and 
its a zero value activity and yet I'm finding my bread and butter code (I write 
iOS apps for a living) increasingly encumbered by Swifty cruft that make no 
sense in a dynamic world .

So -1.

> On Jan 6, 2017, at 03:22, Georgios Moschovitis via swift-evolution 
>  wrote:
> 
>> I don’t really like all the special stuff we do for Obj-C,
> 
> big +1
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

[Freak Show via swift-evolution]

> On Dec 29, 2016, at 13:28, Rod Brown via swift-evolution 
>  wrote:
> 
> I’m in agreement that ‘dynamic’ is probably not what you want without a 
> declaration.

I hold a completely opposite viewpoint.  Dynamic is always what I want and 
table based is premature optimization.  Late binding is important.  I found far 
too often when working in C++ (yes I am really flipping old) I would come 
across code where a developer hadn't chosen to make a method virtual and I 
found myself just up a creek with regards to extending that code.  Ditto people 
declaring stuff final in Java for no good reason.

The important thing to consider is that the future is generally unknowable and 
if you don't know the future you cannot make good choices about what should and 
should not be dynamic.  So the conservative thing is to make everything dynamic 
until you cannot afford it - which...is usually never.

> The only difference between table and method dispatch is the Objective-C 
> message dispatch system. Unless users want to work around things by manually 
> handling with some of the complex machinery in Obj-C, which is rare, then 
> there is no reason behind doing so, and all it comes down to is a relatively 
> large performance hit for nothing. And to be honest, with very few 
> exceptions, if you’re using that ultra-dynamic machinery, you’re probably 
> Doing It Wrong in the first place.

I do this sort of thing routinely and I assure you I am not Doing It Wrong.

I don't get why there is so much emphasis on performance in this day and age.  
I haven't run into a performance problem I could trace to speed of ObjectiveC's 
method dispatching since the early 90's.

Second - I have quite a lot of code that relies on this sort of dynamism. I've 
been a very serious C++ developer and a very serious Smalltalk programmer at 
various times in my career and I value the flexibility of late binding far 
above performance.

> If you need this functionality, dynamic still exists. But Swift is Table 
> Dispatch by default for a reason: you’re paying a massive penalty for 
> something you’ll rarely if ever use, and it should be opt in.

Strongly disagree.  
> 
> 
>> On 15 Dec 2016, at 10:15 am, Brian King via swift-evolution 
>>  wrote:
>> 
>> I wanted to follow up to a blog post I wrote about Message Dispatch in
>> Swift — https://www.raizlabs.com/dev/2016/12/swift-method-dispatch. I
>> mentioned some changes to NSObject that didn’t result in any
>> objections, so I thought it was time to see what the SE mailing list
>> thought.
>> 
>> I’ve read a few conversations on SE mailing list that have morphed
>> into abstract conversations about dynamic vs static dispatch. I want
>> to focus specifically on how Swift NSObject subclasses behave.
>> 
>> I think that there are 2 changes that will result in fewer bugs and
>> will not have a substantial impact on performance:
>> 
>> 
>> ## Remove Table Dispatch from NSObject
>> 
>> NSObject subclasses use table dispatch for the initial class
>> declaration block. I think that using message dispatch for NSObject
>> subclasses everywhere will result in a much more consistent developer
>> experience.
>> 
>> ## Block NSObject Visibility Optimizations
>> 
>> Swift upgrades method dispatch to final when the compiler can prove
>> that the method is not subclassed. I would like to see Swift be more
>> careful about the impact of these optimizations on message dispatch,
>> and consider message dispatch non-upgradable.
>> 
>> 
>> I thought it would help to frame this choice as a trade-off between
>> Swift’s goals of safe, fast, and expressive.
>> 
>> ## Safe
>> 
>> Always using message dispatch for NSObject subclasses will fix a class
>> of runtime errors in framework features that are designed around
>> message passing (e.g. KVO). Arguments against using dynamic features
>> like this are valid, but Cocoa frameworks still use dynamic features
>> and the above behaviors result in actual bugs. As a bonus, this will
>> resolve SR-584, where a table-dispatched method that is overridden by
>> a message dispatch method doesn’t behave correctly.
>> 
>> ## Fast
>> 
>> The above changes will result in slower dispatch in NSObject
>> subclasses. However, I don't think that these dispatch changes
>> actually have a tangible impact on performance. Most NSObject
>> subclasses sit on top of a lot of `objc_msgSend`, and if there is a
>> specific hot spot, it would still be optimizable via the final
>> keyword.
>> 
>> ## Expressive
>> 
>> Using table dispatch for NSObject without any source indication or
>> library documentation is not very expressive. I think it’s important
>> to weigh table dispatch behavior against all of the framework
>> documentation and developer experience that assume message dispatch.
>> This will also eliminate the need for a lot of `@objc` and `dynamic`
>> annotations that are often inconsistently applied depending on if they
>> are needed