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] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

[David Sweeris via swift-evolution]

> On Oct 20, 2017, at 10:54, Eagle Offshore via swift-evolution 
>  wrote:
> 
> +1
> 
> I really feel like the number of modifiers and decorators and annotations 
> etchas reached the point of illegibility.
> 
> It purpose="intensifier">reallyridiculous
> 
> 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.

Agree that annotations can get unwieldy, but how else are we supposed to 
express nuances when the language’s default is wrong for the code in question?

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

Was that position argued during the proposal review? I don’t remember... In any 
case, I think the “very high bar” we have now for breaking source compatibility 
makes it unlikely to change at this point (OTOH, I’m frequently wrong here)

> I'll stop now.

Feel free to voice your concerns... Obviously I can’t promise anyone will agree 
or anything, but if you think you have a point that hasn’t already been 
discussed, we want to hear it! (Or at least I do... I’m just a random dude on 
the internet and don’t “speak for the list” or anything, but that’s been the 
general attitude as long as I’ve been hanging out here)

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