Re: [swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

Yeah, that's what I want - more "annotations" cluttering up my Objective C headers to make Swift happy. No thanks. There's enough noise introduced already. > On Feb 2, 2017, at 07:33, Jonathan Hull via swift-evolution > wrote: > > >> On Feb 2, 2017, at 6:11 AM, David Hart via swift-evolutio

Re: [swift-evolution] Proposal seed: gathering data to fix the NSUInteger inconsistency

I have a framework I wrote that maps Objective C objects to sqlite records - deriving sqlite schema definitions from property definitions. You simply derive model classes from my base class Model and the base class will introspect the properties and handle all the sql for you. A little like C

Re: [swift-evolution] for-else syntax

collection ifEmpty:[ "" ] ifNotEmptyDo: [:each | "" ] > On Feb 1, 2017, at 10:29, Chris Davis via swift-evolution > wrote: > > ah! I forgot about the break semantics, that’s definitely one for the con > list. > > I like Nicolas’ solution, clear to read. > >> On 1 Feb 2017, at 18:

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

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&file=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

Re: [swift-evolution] Optional Assignment Operator

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 desig

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

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

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

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 wr

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

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

Re: [swift-evolution] Reduce with inout

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

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

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.i

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

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 > mailto:swift-evolution@swift.org>> wrote: > >> >> On Jan 11, 2017, at 01:11, Freak Show > > wrote

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

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

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

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 l

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

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

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

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 uniq

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

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 th

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

> On Dec 29, 2016, at 16:34, Dave Abrahams via swift-evolution > wrote: > By that measure there should be no encapsulation; we should make > everything public, because somebody might need it someday. > I don't know what you mean by "encapsulation" but I will explain what I think it means. >F

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

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