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

[Eagle Offshore via swift-evolution]

Hi Magnus,

You raise an excellent point.

The swift journey has been interesting to watch, for sure.  I do not believe 
anyone has ever started with a rigidly typed system and then tried to make it 
more dynamic (Java JVM dynamicInvocation work by Bracha notwithstanding).  
There have been several languages that started out as purely dynamic that then 
added optional type annotations to get compilers to be a little more helpful.  
Strongtalk, Objective C v1, etc.  But starting out with a rigid static bias and 
trying to add in dynamic features seems a lot harder than going the other way.

Anyhow, I have heard for years this argument about how helpful compilers are 
when there is abundant type information.

My experience leaves me personally skeptical but more to the point - where's 
the actual proof?

Here's a blog post with a lot of links to studies trying to assess whether 
static-type heavy systems actually reduce defects and make people more 
productive.
https://danluu.com/empirical-pl/

Don't just read the page, follow the links and read the studies.

This continues to be argued at YCombinator. 
https://news.ycombinator.com/item?id=15384351

And there is this discussion of a talk called "The unreasonable effectiveness 
of dynamic typing".
https://games.greggman.com/game/dynamic-typing-static-typing/

Bottom line - I want to see the proof too.  I think everything should be 
DynamicLookupable - especially library code since the library creator cannot 
know in advance how his code may be used and it may well want to be bridged 
from another environment but then I have been doing a lot of bridging of Pharo 
Smalltalk to native C libraries via FFI lately and I firmly believe bridges 
need to run both ways.

It is easy to bridge Objective C from Smalltalk.  Swift, OTOH, looks nigh 
impossible as it is.

> On Dec 4, 2017, at 10:20 AM, Magnus Ahltorp via swift-evolution 
>  wrote:
> 
> 
>> 5 Dec. 2017 01:08 Benjamin G via swift-evolution  
>> wrote:
>> 
>> Unless DynamicLookup is used to circumvent every compiler warning or errors 
>> thrown at you by the language because your design is unsound. Something like 
>> "ho, yeah swift generics and protocols aren't really working fine together 
>> for your case, but just make everything DynamicLookupable and you'll be all 
>> set". Or "This JSON document has a really complex schema. Let's just not 
>> specify anything, and call the fields like this, you won't even feel any 
>> difference anyway".
> 
> We have heard these horror tales about everyone making "everything 
> DynamicLookupable" and this being extremely bad, but can anyone actually 
> produce a believable example? It's not like it's absurdly convenient to 
> implement this, the ergonomics are at the call site, not the implementation. 
> It sounds like you think that just conforming to DynamicMemberLookupProtocol 
> and DynamicCallable will magically make everything in the code dynamic with 
> no extra effort.
> 
> /Magnus
> 
> ___
> 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] JSONEncoder: Key strategies

[Eagle Offshore via swift-evolution]

I have to agree, would be better to allow one to provide a mapping dictionary 
or delegate.  Building the encodingKeys into the class itself is short sighted 
and a half measure.

Different types of codings will necessarily desire different key sets and even 
different names for what are logically the same keys.  This absolutely should 
NOT be baked into the class that implements Codable but rather maybe a delegate 
that is presented each key/value and given an opportunity to provide a 
substitute key and value.

Codable is a fairly useless one trick pony in its current incarnation.  It 
doesn't really solve any problem I have with respect to interacting with web 
services.

> On Nov 7, 2017, at 2:50 PM, Mike Kluev via swift-evolution 
>  wrote:
> 
> a big fat -1. sorry.
> 
> imho, this is barking up the wrong tree and things like converting from camel 
> case / snake case / removal underscores/ capitalization / etc, etc shall not 
> be part of foundation. even if people in the labs asking for that. third 
> party library - probably.
> 
> more easy way to handle keys customization would be nice, last i checked it 
> was "all or nothing", whenever i wanted to customise a single key i had to do 
> them all and the source tripled in size. something simple to avoid that would 
> be enough, imho.
> 
> Mike
> 
> on Mon, 06 Nov 2017 12:54:38 -0800 Tony Parker  > wrote:
> 
> Hi everyone,
> 
> While we have no formal process at this time for proposals of changes to 
> Foundation-only code, I would still like to post one that we have run through 
> our internal process here for additional public comment.
> 
> Link to PR with proposal content:
> 
> https://github.com/apple/swift-corelibs-foundation/pull/1301 
> 
> 
> Link to implementation for the overlay:
> 
> https://github.com/apple/swift/pull/12779 
>  
>  >
> 
> Markdown follows.
> 
> Thanks,
> - Tony
> 
> # Key Strategies for JSONEncoder and JSONDecoder
> 
> * Proposal: SCLF-0001
> * Author(s): Tony Parker  >
> 
> # Related radars or Swift bugs
> 
> *  Snake case / Camel case conversions for 
> JSONEncoder/Decoder
> 
> # Revision history
> 
> * **v1** Initial version
> 
> ## Introduction
> 
> While early feedback for `JSONEncoder` and `JSONDecoder` has been very 
> positive, many developers have told us that they would appreciate a 
> convenience for converting between `snake_case_keys` and `camelCaseKeys` 
> without having to manually specify the key values for all types
> .
>  
> ___
> 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] Introduce user-defined dynamically "callable" types

[Eagle Offshore via swift-evolution]

They're called Blocks.  Objective C has them.  They're objects.  They're 
actually Objective C objects.

> On Nov 10, 2017, at 10:26 AM, Florent Vilmart via swift-evolution 
>  wrote:
> 
> Object that are functions too, Amazing! I wanted that in Javascript for a 
> while!
> 
> On Nov 10, 2017, 1:04 PM -0500, Joe Groff via swift-evolution 
> , wrote:
>> I don't like the idea of some calls having wildly different semantics from 
>> others; it's difficult enough to tell what exactly a call might be doing 
>> already. Since we also lack the more obvious static "Callable" protocol idea 
>> to give even well-typed call syntax to user-defined types, this also seems 
>> like it'd be easily abused for that purpose too.
>> 
>> I think a much better general solution to the problem of "make dynamic 
>> systems interact with type systems" is something like F#'s type providers 
>> which lets you write your own importers that look at dynamic information 
>> from a database, dynamic language VM, or some other system and generate type 
>> information usable by the compiler. Integration at the importer level could 
>> let you produce more well-typed Swift declarations by looking at the runtime 
>> information you get by importing a Python module.
>> 
>> -Joe
>> 
>>> On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> Hello all,
>>> 
>>> I have a couple of proposals cooking in a quest to make Swift interoperate 
>>> with dynamically typed languages like Python better. Instead of baking in 
>>> hard coded support for one language or the other, I’m preferring to add a 
>>> few small but general purpose capabilities to Swift. This is the first, 
>>> which allows a Swift type to become “callable”.
>>> 
>>> The proposal is here:
>>> https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d
>>> 
>>> I’ve also attached a snapshot below, but it will drift out of date as the 
>>> proposal is refined. Feedback and thoughts are appreciated, thanks!
>>> 
>>> -Chris
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Introduce user-defined dynamically "callable" types
>>> 
>>> • Proposal: SE-
>>> • Author: Chris Lattner
>>> • Review Manager: TBD
>>> • Status: Awaiting implementation
>>> Introduction
>>> 
>>> This proposal introduces a new DynamicCallable protocol to the standard 
>>> library. Types that conform to it are "callable" with the function call 
>>> syntax. It is simple syntactic sugar which allows the user to write:
>>> 
>>> a = someValue(keyword1: 42, "foo", keyword2: 19)
>>> and have it be interpreted by the compiler as:
>>> 
>>> a = someValue.dynamicCall(arguments
>>> : [
>>> (
>>> "keyword1", 42), ("", "foo"), ("keyword2", 19
>>> )
>>> ])
>>> 
>>> Other languages have analogous features (e.g. Python "callables"), but the 
>>> primary motivation of this proposal is to allow elegant and natural 
>>> interoperation with dynamic languages in Swift.
>>> 
>>> Swift-evolution thread: Discussion thread topic for that proposal
>>> 
>>> Motivation
>>> 
>>> Swift is well known for being exceptional at interworking with existing C 
>>> and Objective-C APIs, but its support for calling APIs written in scripting 
>>> langauges like Python, Perl, and Ruby is quite lacking. These languages 
>>> provide an extremely dynamic programming model where almost everything is 
>>> discovered at runtime.
>>> 
>>> Through the introduction of this proposal, and the related 
>>> DynamicMemberLookupProtocol proposal, we seek to fix this problem. We 
>>> believe we can make many common APIs feel very natural to use directly from 
>>> Swift without all the complexity of implementing something like the Clang 
>>> importer. For example, consider this Python code:
>>> 
>>> class Dog
>>> :
>>> 
>>> def __init__(self, name
>>> ):
>>> 
>>> self.name =
>>> name
>>> 
>>> self.tricks = [] # creates a new empty list for each dog
>>> 
>>> 
>>> 
>>> def add_trick(self, trick
>>> ):
>>> 
>>> self.tricks.append(trick)
>>> we would like to be able to use this from Swift like this (the comments 
>>> show the corresponding syntax you would use in Python):
>>> 
>>> // import DogModule
>>> // import DogModule.Dog as Dog // an alternate
>>> let Dog = Python.import(“DogModule.Dog")
>>> 
>>> // dog = Dog("Brianna")
>>> let dog = Dog("Brianna")
>>> 
>>> // dog.add_trick("Roll over")
>>> dog.add_trick("Roll over")
>>> 
>>> // dog2 = Dog("Kaylee").add_trick("snore")
>>> let dog2 = Dog("Kaylee").add_trick("snore")
>>> Of course, this would also apply to standard Python APIs as well. Here is 
>>> an example working with the Python pickleAPI and the builtin Python 
>>> function open:
>>> 
>>> // import pickle
>>> let pickle = Python.import("pickle"
>>> )
>>> 
>>> 
>>> // file = open(filename)
>>> let file = Python.open
>>> (filename)
>>> 
>>> 
>>> // blob = file.read()
>>> let blob = file.read
>>> ()
>>> 
>>> 
>>> // result = pickle.loads(blob)
>>> let result = pickle.loads(blob)

Re: [swift-evolution] continuations - "extensions on steroids" idea

[Eagle Offshore via swift-evolution]

"Continuation" already means something else in computer programming.  I would 
suggest you find another term.

https://en.wikipedia.org/wiki/Continuation


> On Oct 30, 2017, at 6:12 PM, Mike Kluev via swift-evolution 
>  wrote:
> 
> a general feeling that there are two very different use cases of extensions 
> -- one to extend own classes and another to extend other people classes; a 
> lengthy discussion in a nearby thread; a disparity of features of class and 
> it's extensions and different access right treatment depending upon whether 
> the extension is in the same with the main class or a different file lead me 
> to the following idea. hopefully you will find this idea useful and we may 
> even see it one day in swift.
> 
> introducing class / struct / enum continuations.
> 
> in a few words the are:
> 
> 1) "extensions on steroids". in fact very similar to Objective-C "class 
> extensions" but can be more than one and in more than one file.
> 
> 2) as good as the classes they continue (or other continuations they continue)
> 
> 3) can declare variables
> 
> 4) have full access to "private" members of the class or other continuations
> regardless whether they are in the same or in a different files. no need for 
> "public/internal/module" fallbacks to pass though files boundaries. similarly 
> the class itself can use private members of its continuations.
> 
> 5) "by invitation only" system. can only be written if declared by the class 
> or some continuation of it.
> 
> 6) A particular continuation only defined once (of course). There can be an 
> arbitrary number of different continuations to a class similar to extensions.
> 
> 7) alternative name considered: "extending" (as a noun). shall definitely be 
> a different name than say, "extension" with some bracket-syntax variation - 
> the two use cases are very different and shall be named differently.
> 
> 8) the particular syntax is preliminary of course. 
> 
> example:
> 
> = Some.swift ==
> 
> class Some {
> 
> private func private_method_of_class() {
> 
> // *** can use private methods of continuations even if they are in a 
> different file
> private_method_defined_in_a_continuation()
> }
> 
> // *** "by invitation" system
> 
> continuation Feature  // *** declaring a continuation
> continuation SomethingElse// *** Capitalized names, like classes
> }
> 
> = Some-Feature.swift ==
> 
> // *** similar naming convetion to "Some+Feature.swift"
> // used for extensions, just with "-" instead
> 
> // *** this is merely a naming convention, no need to
> necessarily follow it, can put more than one thing into
> a file, the continuation can reside in the same file as
> the main class fie, etc.
> 
> continuation Feature of Some {
> 
> // *** as good as class itself. first-class citizen
> // *** same syntax can be used for structs and enums
> 
> var x: Int // *** can declare variables
> 
> private func private_method_defined_in_a_continuation() {
> private_method_of_class()
> 
> // *** can use private methods of the class or of other
> continuations even if they are in a different file
> }
> 
> // *** continuations are as good as classes and can
> // *** declare other continuations if needed
> 
> continuation CanDoThis
> }
> 
> = Any file ==
> 
> continuation Feature of Some { // *** error, continuation is already defined
> }
> 
> continuation Other of Some { // *** error: Other is not a continuation of Some
> }
> 
> thoughts?
> 
> Mike
> 
> ___
> 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] [SPM] Roadmap?

[Eagle Offshore via swift-evolution]

Without a better C/C++ integration story, Swift is still born in my world.

> On Oct 28, 2017, at 8:04 AM, Goffredo Marocchi via swift-evolution 
>  wrote:
> 
> Very well said, I kind of think that at this point in time you do much more 
> for the language by investing into SPM properly than Actors/Coroutines if you 
> had to choose.
> 
> Sent from my iPhone
> 
> On 28 Oct 2017, at 14:26, Karl Wagner via swift-evolution 
> > wrote:
> 
>> 
>>> On 23. Oct 2017, at 19:41, Jean-Christophe Pastant via swift-evolution 
>>> > wrote:
>>> 
>>> Hi,
>>> 
>>> Is there any news about features that are willling to be integrated into 
>>> SPM 5?
>>> Those I see the most relevant:
>>> - iOS support
>>> - Some kind of configuration/settings support (debug, release, ...)
>>> 
>>> I'd like to hear about it from maintainers, especially if there's a 
>>> priority order we should follow.
>>> 
>>> Regards,
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> Yup. My opinions here: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170918/039885.html
>>  
>> .
>>  Basically, I think we need support for 1) resources (or ‘assets’) and 2) 
>> cross-platform modules.
>> 
>> I think that a better package-manager would really accelerate the Swift 
>> ecosystem. We’ve had lots of people complaining about the lack of quality 
>> libraries (e.g. for maths and stats) during the Swift 3/4 phases. 
>> Personally, I still think it’s too much effort to integrate 3rd-party 
>> library projects in to my existing projects and to contribute to them, which 
>> is why I usually don’t.
>> 
>> As for Xcode integration: Obviously only Apple can comment on the Xcode 
>> roadmap - but I will point out that, like the rest of Swift and LLVM, the 
>> package manager is open-source and designed with a library architecture. 
>> That means that any IDE could integrate support for SwiftPM, not just Xcode. 
>> As users, we can say what we’d like Apple to do with Xcode, but it’s all 
>> academic - since SwiftPM doesn’t support bundled assets, it can’t support 
>> graphical applications. Bundled assets aren’t just an issue for GUI 
>> applications, though - localisation tables, prepared databases and test 
>> resources are useful for any kind of package.
>> 
>> So, for me the issue with assets is that some platforms have unique compiled 
>> formats (e.g. Apple’s asset catalogues) which support asset variants for 
>> localisations and display resolution. Obviously I want my output App to 
>> support all of these features. In fact, most modern platforms have support 
>> for some kind of asset variants — Apple calls it a TraitCollection, Android 
>> calls it a Context — so do we want to support this concept natively somehow 
>> in SwiftPM?
>> 
>> I mean, let’s say I have this awesome cross-platform Swift 
>> application/library, and I’ve listed some files in my Package.swift and I 
>> can find them again at runtime on any platform - all cool. Now, I want to 
>> localise my package - what do I do? I’m going to have to create some 
>> middleware to translate platform-specific concepts in to a baseline which I 
>> can look-up based on some mangling I’m going to create for the file names. 
>> Localisation is a problem on servers, too (particularly for error messages), 
>> so some idea of asset variants could be something universal-enough to 
>> include in the package manager.
>> 
>> - Karl
>> ___
>> 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] Support for a KeyCodingStrategy option in JSONEncoder and JSONDecoder

[Eagle Offshore via swift-evolution]

> On Oct 23, 2017, at 3:19 AM, Mike Kluev via swift-evolution 
>  wrote:
> 
> having Codable does not contradict having introspection / reflection. 

But we don't have general introspection/reflection/dynamic invocation.  Which 
would have been a more worthwhile thing to spend time on as it enables many 
more features.

> general (or shall we say custom) approaches that use introspection / 
> reflection tend to work much slower (from Objective-C experience). i have no 
> data if Codable is performant in these regards but at least it has a 
> potential to be more optimal than a general solution based on introspection / 
> reflection.

Performance is at the very bottom of my list of things I care about - 
especially with regard to JSON processing or other format translations where 
the program is IO bound.

My Objective C KVC based mapper to SQLite was incredibly performant with mapkit 
when I was mapping thousands of pins stored in a very large local database.  
Performance, as an argument against flexibility, is completely unpersuasive.

Stuff is much more than fast enough in the application domain. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Eagle Offshore via swift-evolution]

> On Oct 20, 2017, at 2:55 PM, David Sweeris via swift-evolution 
>  wrote:
> 
> how else are we supposed to express nuances when the language’s default is 
> wrong for the code in question?

Fix the defaults?

Honestly, I'm not sure how I've been programming for so long (30+ years) 
without having to add half a dozen annotations to every single declaration.

"If you think C++ is not overly complicated, just what is a protected abstract 
virtual base pure virtual private destructor and when was the last time you 
needed one? 
— Tom Cargill"

Same applies to Swift at this point.  Its jumped the shark on annotations.


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

Re: [swift-evolution] Support for a KeyCodingStrategy option in JSONEncoder and JSONDecoder

[Eagle Offshore via swift-evolution]

Yes, in general, I think Codable is a poor solution for json decoding just like 
I never used NSCoding to convert JSON to and from objects.  It feels clumsy.

I found it a much better solution to add a category to NSObject that had

-(NSData*)toJSONRepresentationWithMappings:(NSDictionary*)d
+()fromJSONRepresentation:(NSData*) mappings:(NSDictionary*)d

where mappings might be { @"firstName": @"first_name", etc }

and was simple to write a general solution using introspection and KVC.

Codable is a limited one trick pony that would be trivial to write as a trait 
or extension if Swift provided the more profound thing - introspection and 
reflection.  A whole world of opportunities would open up with that and we 
could stop wasting time on Codable and KeyPath - neither of which is that 
useful when working with string data from the wild.

Please stop messing about with these lil special cases and provide a general 
introspection and reflection capability.  Until Swift has that, I might as well 
use C++.

> On Oct 19, 2017, at 2:03 AM, Morten Bek Ditlevsen via swift-evolution 
>  wrote:
> 
> Hi all,
> At work we have just added Codable support for a whole bunch of model objects 
> in our code base.
> Many places we have added CodingKeys enumeration in order to convert the 
> camel cased property names to snake case for our JSON keys.
> As an experiment I have tried adding a KeyCodingStrategy option to a copy of 
> the JSONEncoder and JSONDecoder implementations.
> This is currently an enumeration with the following values
> .original
> .snakeCase
> .custom((String) -> String)
> 
> I just extended CodingKey as follows:
> extension CodingKey {
> func stringValue(with encodingStrategy: 
> StructuralEncoder.KeyEncodingStrategy) -> String {
> switch encodingStrategy {
> case .original:
> return stringValue
> case .snakeCase:
> let pattern = "([a-z0-9])([A-Z])"
> let regex = try! NSRegularExpression(pattern: pattern, options: 
> [])
> let range = NSRange(location: 0, length: 
> stringValue.characters.count)
> return regex.stringByReplacingMatches(in: stringValue, options: 
> [], range: range, withTemplate: "$1_$2").lowercased()
> case .custom(let t):
> return t(stringValue)
> }
> }
> }
> 
> and then I replaced all references to key.stringValue with 
> key.stringValue(with: self.encoder.options.keyCodingStrategy)
> 
> This seems to work very nicely.
> 
> So my question is: Do anyone else see the benefit of such an addition to the 
> JSONEncoder and JSONDecoder?
> 
> The downside as I see it, is that the current CodingKeys are guaranteed to be 
> unique by the compiler, and it would be possible to create collisions by 
> using key name transforms.
> Is this downside bigger than the gains?
> 
> One advantage is that one could argue that one CodingKey strategy may not fit 
> all serialization mechanisms. For instance one might wish to have upper camel 
> cased keys in Plists (just an example) and snake case in JSON. This method 
> could easily support this, while the current CodingKeys strategy cannot...
> 
> Looking forward to hearing feedback.
> 
> Sincerely,
> /morten
> 
> ___
> 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] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[Eagle Offshore via swift-evolution]

+1

I really feel like the number of modifiers and decorators and annotations 
etchas reached the point of illegibility.

Itreallyridiculous

That's what trying to read swift is getting to be like.

Trying to make every single nuance explicit is a fool's errand and is killing 
readability. 

Also, the choice to discard a result is properly the provenance of the caller, 
not an intrinsic feature of a function.

I'll stop now.

> On Oct 15, 2017, at 5:35 AM, Geordie Jay via swift-evolution 
>  wrote:
> 
> I've always read it (frustratingly) as e.g. "func throws Bool", which it 
> doesn't, it throws an Error.

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

Re: [swift-evolution] Support for a KeyCodingStrategy option in JSONEncoder and JSONDecoder

[Eagle Offshore via swift-evolution]

Yes, in general, I think Codable is a poor solution for json decoding just like 
I never used NSCoding to convert JSON to and from objects.  It feels clumsy.

I found it a much better solution to add a category to NSObject that had

-(NSData*)toJSONRepresentationWithMappings:(NSDictionary*)d
+()fromJSONRepresentation:(NSData*) mappings:(NSDictionary*)d

where mappings might be { @"firstName": @"first_name", etc }

and was simple to write a general solution using introspection and KVC.

Codable is a limited one trick pony that would be trivial to write as a trait 
or extension if Swift provided the more profound thing - introspection and 
reflection.  A whole world of opportunities would open up with that and we 
could stop wasting time on Codable and KeyPath - neither of which is that 
useful when working with string data from the wild.

> On Oct 19, 2017, at 8:09 AM, Tony Parker via swift-evolution 
>  wrote:
> 
> Hi Morten,
> 
> I’ve actually been working on this same idea already and will have something 
> to propose soon.
> 
> - Tony
> 
>> On Oct 19, 2017, at 2:03 AM, Morten Bek Ditlevsen via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> At work we have just added Codable support for a whole bunch of model 
>> objects in our code base.
>> Many places we have added CodingKeys enumeration in order to convert the 
>> camel cased property names to snake case for our JSON keys.
>> As an experiment I have tried adding a KeyCodingStrategy option to a copy of 
>> the JSONEncoder and JSONDecoder implementations.
>> This is currently an enumeration with the following values
>> .original
>> .snakeCase
>> .custom((String) -> String)
>> 
>> I just extended CodingKey as follows:
>> extension CodingKey {
>> func stringValue(with encodingStrategy: 
>> StructuralEncoder.KeyEncodingStrategy) -> String {
>> switch encodingStrategy {
>> case .original:
>> return stringValue
>> case .snakeCase:
>> let pattern = "([a-z0-9])([A-Z])"
>> let regex = try! NSRegularExpression(pattern: pattern, options: 
>> [])
>> let range = NSRange(location: 0, length: 
>> stringValue.characters.count)
>> return regex.stringByReplacingMatches(in: stringValue, options: 
>> [], range: range, withTemplate: "$1_$2").lowercased()
>> case .custom(let t):
>> return t(stringValue)
>> }
>> }
>> }
>> 
>> and then I replaced all references to key.stringValue with 
>> key.stringValue(with: self.encoder.options.keyCodingStrategy)
>> 
>> This seems to work very nicely.
>> 
>> So my question is: Do anyone else see the benefit of such an addition to the 
>> JSONEncoder and JSONDecoder?
>> 
>> The downside as I see it, is that the current CodingKeys are guaranteed to 
>> be unique by the compiler, and it would be possible to create collisions by 
>> using key name transforms.
>> Is this downside bigger than the gains?
>> 
>> One advantage is that one could argue that one CodingKey strategy may not 
>> fit all serialization mechanisms. For instance one might wish to have upper 
>> camel cased keys in Plists (just an example) and snake case in JSON. This 
>> method could easily support this, while the current CodingKeys strategy 
>> cannot...
>> 
>> Looking forward to hearing feedback.
>> 
>> Sincerely,
>> /morten
>> 
>> ___
>> 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] Explicit Synthetic Behaviour

[Eagle Offshore via swift-evolution]

> On Sep 6, 2017, at 1:32 AM, Haravikk via swift-evolution 
>  wrote:
> 
> As a general rule I would argue that Mirrors should almost never be used for 
> any purpose, except perhaps debugging; in production code they can lead to 
> subtle and misleading problems, not to mention any performance impacts. Even 
> for things like serialising types, it is not a desirable way to do it, and 
> should only be used as a last resort because of missing features in Swift.


I'm just going to toss in that you and I apparently have diametrically opposed 
needs and belief systems about what makes for a good programming language.  I 
believe the exact opposite.

After 20+ years of Cocoa development, I rely on these features heavily and 
consider any language that lacks them to be more or less "dead" where I 
consider languages that have them to be "self aware" and "lively".

For instance, I think relying on the compiler to generate special code to 
implement Codable rather than just exposing the meta facilities required to do 
introspection is taking the long way around rather than the short cut.

So add my vote for powerful reflection capabilities.  
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Concurrency] async/await + actors

[Eagle Offshore via swift-evolution]

OK, I've been watching this thing for a couple weeks.

I've done a lot of GCD network code.  Invariably my completion method starts 
with

dispatch_async(queue_want_to_handle_this_on,)

Replying on the same queue would be nice I guess, only often all I need to do 
is update the UI in the completion code.

OTOH, I have situations where the reply is complicated and I need to persist a 
lot of data, then update the UI.

So honestly, any assumption you make about how this is supposed to work is 
going to be wrong about half the time unless

you let me specify the reply queue directly.

That is the only thing that works all the time.  Even then, I'm very apt to 
make the choice to do some of the work off the main thread and then queue up 
the minimal amount of work onto the main thread.

Finally, I don't think this is properly a language feature.  I think its a 
library feature.  I think Swfit's tendency is to push way too much into the 
language rather than the library and I personally STRONGLY prefer tiny 
languages with rich libraries rather than the opposite.  

That's my $0.02.  I don't care about key words for async stuff.   I'm more than 
happy with GCD the library as long as I have the building blocks (closures) to 
take advantage of it.

> On Sep 5, 2017, at 6:06 PM, Pierre Habouzit via swift-evolution 
>  wrote:
> 
>> On Sep 5, 2017, at 5:29 PM, Elliott Harris via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Sep 4, 2017, at 11:40 AM, Pierre Habouzit via swift-evolution 
>>> > wrote:
>>> 
 On Sep 4, 2017, at 10:36 AM, Chris Lattner via swift-evolution 
 > wrote:
 
 On Sep 3, 2017, at 12:44 PM, Pierre Habouzit > wrote:
> My currently not very well formed opinion on this subject is that GCD 
> queues are just what you need with these possibilities:
> - this Actor queue can be targeted to other queues by the developer 
> when he means for these actor to be executed in an existing execution 
> context / locking domain,
> - we disallow Actors to be directly targeted to GCD global concurrent 
> queues ever
> - for the other ones we create a new abstraction with stronger and 
> better guarantees (typically limiting the number of possible threads 
> servicing actors to a low number, not greater than NCPU).
 
 Is there a specific important use case for being able to target an 
 actor to an existing queue?  Are you looking for advanced patterns 
 where multiple actors (each providing disjoint mutable state) share an 
 underlying queue? Would this be for performance reasons, for 
 compatibility with existing code, or something else?
>>> 
>>> Mostly for interaction with current designs where being on a given 
>>> bottom serial queue gives you the locking context for resources 
>>> naturally attached to it.
>> 
>> Ok.  I don’t understand the use-case well enough to know how we should 
>> model this.  For example, is it important for an actor to be able to 
>> change its queue dynamically as it goes (something that sounds really 
>> scary to me) or can the “queue to use” be specified at actor 
>> initialization time?
> 
> I think I need to read more on actors, because the same way you're not an 
> OS runtime expert, I'm not (or rather no longer, I started down that path 
> a lifetime ago) a language expert at all, and I feel like I need to 
> understand your world better to try to explain this part better to you.
 
 No worries.  Actually, after thinking about it a bit, I don’t think that 
 switching underlying queues at runtime is scary.
 
 The important semantic invariant which must be maintained is that there is 
 only one thread executing within an actor context at a time.  Switching 
 around underlying queues (or even having multiple actors on the same 
 queue) shouldn’t be a problem.
 
 OTOH, you don’t want an actor “listening” to two unrelated queues, because 
 there is nothing to synchronize between the queues, and you could have 
 multiple actor methods invoked at the same time: you lose the protection 
 of a single serial queue. 
 
 The only concern I’d have with an actor switching queues at runtime is 
 that you don’t want a race condition where an item on QueueA goes to the 
 actor, then it switches to QueueB, then another item from QueueB runs 
 while the actor is already doing something for QueueA.
 
 
>>> I think what you said made sense.
>> 
>> Ok, I captured this in yet-another speculative section:
>> 

Re: [swift-evolution] [Pitch] Improving KeyPath

[Eagle Offshore via swift-evolution]

Reflection mechanisms in general would let one make things like Codable and 
Keypaths simply a library capability/protocol extension rather than the special 
case one trick pony it is now.

More than any other feature discussed, full access to meta data such as memory 
layouts is the thing I most miss from Objective C.  

Given reflection/introspection, you can build KVC, Codable, and any number of 
other clever features yourself if you are so inclined.

Oh, and traits - want traits for composability.

> On Aug 25, 2017, at 11:43 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> These would all be great additional features to eventually add to key paths. 
> I think reflection mechanisms centered on key paths like what you describe 
> would be a superior replacement for most of what Mirror attempts to provide.

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

Re: [swift-evolution] (core library) modern URL types

[Eagle Offshore via swift-evolution]

I liked the polymorphic identifiers paper presented at Dynamic Languages 
Symposium 2013.

http://dl.acm.org/citation.cfm?doid=2508168.2508169 


There's a lot of power in URI's that remains largely untapped in most systems.

There's not a great reason for this heterogeneity other than historical baggage.

Properly done, URI's can unify keypaths, user defaults, environment variables, 
files, network stores, databases, etc.


> On Aug 22, 2017, at 12:52 PM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> Just leaving it out here that the iOS/macOS app experience with paths is 
> likely to be very different from the server (or system program) experience. 
> Most of your paths are relative to a container because the effective root of 
> your data is the container. I would tend to believe that a lot of your paths, 
> not while fully static, could be expressed with something like 
> "${DOCUMENTS}/static/part", where ${DOCUMENTS} is the only thing that 
> effectively changes. A system-level program just happens to use / as its 
> prefix.
> 
> Most platforms already have some notion of file domains, which are really 
> just path prefixes (the user's home folder, the file system root, the network 
> root, etc). I think that some level of support for these would be desirable 
> (would it be only a set of functions that return different path prefixes). 
> It's also my humble opinion that tilde expansion should be part of a larger 
> shell expansion feature to avoid surprises.
> 
> I think that I support the conclusion.
> 
> Félix
> 
> Le 22 août 2017 à 12:02, Dave DeLong  a écrit :
> 
>> I suppose, if you squint at it weirdly.
>> 
>> My current Path API is a “Path” protocol, with “AbsolutePath” and 
>> “RelativePath” struct versions. The protocol defines a path to be an array 
>> of path components. The only real difference between an AbsolutePath and a 
>> RelativePath is that all file system operations would only take an 
>> AbsolutePath. A URL would also only provide an AbsolutePath as its “path” 
>> bit.
>> 
>> public enum PathComponent {
>> case this // “."
>> case up   // “..” 
>> case item(name: String, extension: String?)
>> }
>> 
>> public protocol Path {   
>> var components: Array { get }
>> init(_ components: Array) // used on protocol extensions 
>> that mutate paths, such as appending components
>> }
>> 
>> public struct AbsolutePath: Path { }
>> public struct RelativePath: Path { }
>> 
>> By separating out the concept of an Absolute and a Relative path, I can put 
>> additional functionality on each one to make semantic sense (you cannot 
>> concatenate two absolute paths, but you can concat any path with a relative 
>> path, for example). Or all file system operations must take an AbsolutePath. 
>> 
>> One of the key things I realized is that a “Path” type should not be 
>> ExpressibleByStringLiteral, because you cannot statically determine if a 
>> Path should be absolute or relative. However, one of the initializers for an 
>> AbsolutePath would handle things like expanding a tilde, and both types try 
>> to reduce a set of components as much as possible (by filtering out “.this” 
>> components, and handling “.up” components where possible, etc). Also in my 
>> experience, it’s fairly rare to want to deal with a known-at-compile-time, 
>> hard-coded path. Usually you’re dealing with paths relative to known 
>> “containers” that are determined at runtime (current user’s home folder, 
>> app’s sandboxed documents directory, etc).
>> 
>> Another thing I’ve done is that no direct file system operations exist on 
>> AbsolutePath (like “.exists” or “.createDirectory(…)” or whatever); those 
>> are still on FileManager/FileHandle/etc in the form of extensions to handle 
>> the new types. In my app, a path is just a path, and it only has meaning 
>> based on the thing that is using it. An AbsolutePath for a URL is used 
>> differently than an AbsolutePath on a file system, although they are 
>> represented with the same “AbsolutePath” type.
>> 
>> I’m not saying this is a perfect API of course, or even that a hypothetical 
>> stdlib-provided Path should mimic this. I’m just saying that for my 
>> use-case, this has vastly simplified how I deal with paths, because both URL 
>> and String smell really bad for what I’m doing.
>> 
>> Dave
>> 
>>> On Aug 22, 2017, at 12:37 PM, Taylor Swift >> > wrote:
>>> So are you saying we need three distinct “URI” types for local-absolute, 
>>> local-relative, and remote? That’s a lot of API surface to support.
>>> 
>>> On Tue, Aug 22, 2017 at 12:24 PM, Dave DeLong >> > wrote:
>>> I completely agree. URL packs a lot of punch, but IMO it’s the wrong 
>>> abstraction for file system paths.
>>> 
>>> I maintain an app that deals a lot with file system paths, and