> Am 27.09.2016 um 01:04 schrieb Robert Widmann via swift-evolution
> <swift-evolution@swift.org>:
>
> Being a power user of this feature, I don’t think the existing syntax is
> cumbersome enough to warrant this kind of shortcut. I really like being able
> to
>
> guard case let .dict(book) = data else {
> // bail out
> }
> guard case let .dict(author) = book["author"] ?? .null else {
> // bail out
> }
> guard case let .integer(age) = author["age"] ?? .null else {
> // bail out
> }
>
> // now we have the age
>
> or more succinctly
>
> guard case let .dict(book) = data,
> case let .dict(author) = book["author"] ?? .null,
> case let .integer(age) = author["age"] ?? .null
> else {
> // bail out
> }
> // now we have the age
This is a very nice and readable solution. IMHO much better than the proposed
syntax.
-Thorsten
>
> Because it forces me to think about the bailout case(s) and is really not
> that much longer than your proposed syntax
>
> guard let book = case? .dict(inputData),
> let author = case? .dict(book?["author”]),
> let age = case? .integer(author?["age”])
> else {
> // bail out
> }
> // now we have the age
>
> ~Robert Widmann
>
>> On Sep 26, 2016, at 11:51 AM, Jérôme Duquennoy via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> Summary
>> The aim of this proposal is to offer a new syntax to ease some uses of enums
>> with payload.
>>
>> Situation to improve:
>> Enums makes it possible to have explicate typing where it was not possible
>> before. A classic example of that is filling a dictionary with data coming
>> from a file or a stream (json, plist, …) : the types of possible values is
>> finite : arrays, dicts, int, double, bool or string for json for exemple.
>> An enum can represent this finite range of possible types, its make the code
>> and the API more self-documented.
>> Then, you have two possibilities to deal with this enum:
>> - using switch statements
>> - using the if case syntax introduced by swift 2
>>
>> The drawback is that those two solutions can lead to writing code with high
>> visual complexity, even though the logic behind is pretty simple.
>>
>> Consider this example of a data dictionary, that a web service could have
>> returned:
>> - book
>> - title:
>> - author:
>> - name: Apple
>> - age: 40
>>
>> We can decode this in a variable of type [String:Value], where Value is:
>>
>> enum Value {
>> case integer(value: Int)
>> case string(value: String)
>> case dict(value: [String:Value])
>> case null
>> }
>>
>> Here is a snippet of code to access the age of the author:
>>
>> if case .dict(let book) = data {
>> if case .dict(let author) = book["author"] ?? .null {
>> if case .integer(let age) = author["age"] ?? .null {
>> // now we have the age
>> }
>> }
>> }
>>
>> The multiple indentation levels can rapidly make this code unattractive to
>> read, and we need to add a null case to the enum to deal with optional
>> values.
>>
>> Proposed solution:
>> I suggest to add a new syntax, using the case keyword to ease access to the
>> payload of such enums :
>>
>> let payloadContent = case? .enumCase(variable)
>>
>> The payloadContent variable will be an optional, that can be either nil, or
>> contain the payload of enumCase.
>> If the payload contains multiple variables, payloadContent will be a tupple.
>> This syntax can accommodate an optional variable as an input. If the value
>> of variable is nil, then payloadContent will be nil.
>> Only enum cases with a payload can be used with this syntax (it would make
>> no sens for cases without a payload).
>>
>> With that syntax, the null case of the enum can be removed, and the code to
>> access the age becomes:
>>
>> let book = case? .dict(inputData)
>> let author = case? .dict(book?["author"])
>> let age = case? .integer(author?["age"])
>>
>> Advantages:
>> - It leverages the well established notion of optional, and similar logic
>> already exists in the language (for the as? operator notably).
>> - It does not add a new keyword
>> - It promotes the use of enum to enforce explicit typing, which leads to
>> more self-documenting code
>> - It reduces the complexity of the code in situations such as the one of the
>> exemple
>>
>> Drawbacks:
>> - It adds a third use of the case keyword.
>> - In the proposed syntax, the variable between parenthesis is not the
>> payload, but the variable to decode. This might be disturbing, as it differs
>> from the other syntax of enum values.
>> - If the payload is an optional, it is not possible to differentiate a
>> non-matching case and a matching case a nil payload.
>>
>> Alternatives:
>> - Another syntax without parenthesis could be used to avoid the second
>> drawback:
>> let payload = case? .enumCase variable
>>
>> Impact on existing code:
>> None, this is adding a new syntax
>>
>>
>> This proposal would have no impact on the ABI, so it probably does not fit
>> the stage 1 of swift 4’s roadmap. But I would be glad to have your feedback,
>> so that I can have a proposal ready once we enter stage 2.
>> So what your thoughts on that proposal ?
>>
>> Thanks
>>
>> Jerome
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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
