Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral
I used a DictionaryLiteral only yesterday, and it turned what would have a typically unreadable array of Structs into something much more elegant. I'm pretty sure the only reason Literals (of all varieties) aren't used more often is because Swift programmers don't realize they are available and easy to implement. Sent from my telephone > On Jan 8, 2018, at 9:40 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > >> On Mon, Jan 8, 2018 at 11:53 PM, Xiaodi Wu via swift-evolution >> wrote: >> Thank you for the clarification. It occurred to me in the shower that this >> might be the case, and that I was entirely mistaken as to what we were >> talking about. >> >> Yes, then, I wholeheartedly agree on this point. Out of curiosity, why are >> there source stability issues to 'typealias DictionaryLiteral = >> [(Key, Value)]'? > > Because at the point of use, “DictionaryLiteral” is instantiated with an > actual dictionary literal, eg. “[a: 1, b: 2, c: 3]”, and that syntax isn’t > available for an array of key-value pairs. As near as I can tell, the > convenience of that spelling is the entire raison-d’être for > “DictionaryLiteral” in the first place. > > The ulterior question of whether preserving “DictionaryLiteral” is > worthwhile, is apparently out of scope. Personally, I have a hard time > imagining a compelling use-case outside of the standard library, and I doubt > it’s being used “in the wild” (I checked several projects in the > source-compatibility suite and found zero occurrences). > > Nevin > ___ > 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] Annotation of Warnings/Errors
+1 Strongly in favour of this one. One of those things that seems obvious in retrospect It would also make the language more enjoyable to code in. When Xcode nags me about my function not providing a return value when I've only just started writing it, I get the irrational urge to tell Xcode to shut its (metaphorical) mouth. Using context to tell me errors "just in time" would be much more Apple-like. Sent from my iPhone > On Jan 25, 2017, at 3:59 PM, Karl Wagner via swift-evolution > wrote: > > >> On 26 Jan 2017, at 00:46, Jonathan Hull via swift-evolution >> wrote: >> >> One of the biggest issues that I saw while teaching Swift to newbies (most >> had not programmed before) is confusion based on the early warnings/errors >> that swift/xcode gives you as they type. What would happen is that they >> would type a variable, and it would say… “You haven’t used this variable” >> and so they would just click the fixit because they trust the compiler more >> than they trust themselves. This would lead to a point where they were very >> confused because some of the code was code they had thought through, and >> some of it was changed by random fixits in ways they didn’t understand… and >> so it would lead to more errors/fixits until they had errors which couldn’t >> be fixed. >> >> By the end of the semester they had learned to ignore the warnings until >> they were finished, but it took a couple of months to get there, and was a >> big deterrent to new users… (Also, learning to ignore warnings ignorer to >> use a system seems like an anti-pattern) >> >> I have a good friend who is an expert perl programmer who tried Swift and >> eventually gave up because he couldn’t figure out which errors to ignore >> (and which might just disappear a minute later) and which he needed to pay >> attention to. He was overwhelmed by the sheer number, and they didn’t seem >> trustworthy to him (“Swift is full of lies!” he would say of the warnings… >> which is a mantra I find myself parroting when I get those >> appearing/disappearing errors). >> >> >> To fix this, I propose adding a way to annotate warnings/errors to say how >> immediate they need to be: >> • Immediate - This error should always be shown >> • DifferentLine - This error should only be shown once the cursor is on a >> different line >> • DifferentScope - This error should only be shown once the cursor is in a >> different scope from this line >> • DifferentFunction - This error should only be shown once the cursor is in >> a different function >> >> So the “You haven’t used this variable” warning would be marked >> .differentScope, meaning that it would only show up once you had clicked >> away from the scope. The reason for this is that while you are in the same >> scope, it is fairly likely that you are still going to use the variable… so >> the warning is premature. Once I have left the scope, it makes sense to warn >> me. >> >> Similarly, the “You need a return value” error would be marked >> .differentFunction because you are likely to add one while typing the >> function. But a type mismatch with the return value would either be >> .immediate or .differentLine because you have made an error that isn’t >> likely to be fixed with more typing on other lines. >> >> I think this will cut way down on the number of warnings/errors that need to >> be ignored, which should increase trust in the system overall. >> >> To be clear, I am only proposing adding the annotation to Swift (probably >> with a default of .differentLine). The compiler would not repress the >> warning/error itself… just vend it with a way to retrieve the annotation. >> IDE makers like Apple/Xcode would then be free to use that extra information >> in their UI if desired. >> >> Thanks, >> Jon >> ___ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > Having warnings and errors vanish and then reappear as you click in/out of > function seems far more confusing to me. Is there any other language/IDE that > does things that way? > > - 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
Re: [swift-evolution] [Pitch] Use "where" in combination with "??" to provide Ternary-like functionality
I'm not actually familiar with the term "tri op" but if you're referring to the
ternary, it's only useful when you two, or three items.
If you chain a ternary to use more than three options it becomes error-prone
and almost impossible for a human to read
When I'm at my desktop I'll add a couple better examples of what I'm proposing.
Sent from my iPhone
> On May 23, 2016, at 6:18 PM, Dany St-Amant wrote:
>
>
> Why reinvent the wheel, when the old trusty (but a bit cryptic according to
> some) tri-op can do the trick…
>
>> Le 23 mai 2016 à 04:29, Charles Constant via swift-evolution
>> a écrit :
>>
>> Here's a few examples of what this change would allow.
>>
>> I just plucked the first instances of other people's switch statements that
>> I found on GitHub.
>>
>> If there were an easy way to search GitHub for chained ternary expressions,
>> I would have added some examples of those too, since they could all be
>> improved with this where clause + ??.
>>
>>
>> mutating func toggle() {
>> switch self{
>> case Off:
>> self = On
>> case On:
>> self = Off
>> }
>> }
>>
>>
>>
>> mutating func toggle() {
>> self = .On where (self == .Off) ?? .Off
>> }
>
> mutating func toggle() { self = self == .Off ? .On : .Off }
>
>>
>> switch switchNumberThree {
>> case 10, 11, 12:
>> println("It is \(switchNumberThree)")
>> default:
>> ("It is none of them!")
>> }
>>
>>
>> println(
>> "It is \(switchNumberThree)" where 10...12 ~= switchNumberThree
>> ?? "It is none of them!"
>> )
>
> print( 10...12 ~= switchNumberThree ? "It is \(switchNumberThree)"
>: "It's none of them" )
>
>>
>> switch x {
>> case 1:
>> j++
>> case 2:
>> j++
>> case 3:
>> j++
>> case 4:
>> j++
>> fallthrough
>> case 5:
>> j++
>> fallthrough
>> default:
>> j++
>> }
>>
>>
>> j = j+1 where (4...5 ~= x) ?? j+2
>
> Broken conversion:
> j += 4...5 ~= x ? 1 : 2
>
> Proper conversion:
> j += 4 ~= x ? 3 : 5 ~= x ? 2 : 1
>
> Earlier e-mail example:
>> let foo =
>> "positive" where ( bar > 0 ) ??
>> "negative" where ( bar < 0 ) ??
>> "zero"
>
> let foo = bar > 0 ? "positive" :
> bar < 0 ? "negative" :
> "zero"
>
> Dany
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!
> Well known acronym capitalization is pervasive in Cocoa APIs and as a result > it enables fast and easy comprehension and writing a good quality code. I could reply "they are confusing because they look like class names and clearly cause a higher number of errors in code." My *actual* view is that both forms cause problems, so it doesn't much matter which we go with. Sent from my iPhone > On May 19, 2016, at 1:30 PM, Pavel Kapinos > wrote: > > Hi Charles, > > Thank you for your feedback! But we are not talking here bad or good names > per se. Well known acronym capitalization is pervasive in Cocoa APIs and as a > result it enables fast and easy comprehension and writing a good quality > code. IMO it is quite important for future preservation in Swift 3. Have a > good day! > > Cheers, > Pavel. > >> On May 19, 2016, at 1:20 PM, char...@charlesism.com >> wrote: >> >> I don't believe there's a correct answer here. Both urlHandler and >> URLHandler are bad names (for instances). Since we're stuck with camelCase, >> bad names are a fact of life. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] SE-0005 ==> Please keep well know acronyms capitalized!
I don't believe there's a correct answer here. Both urlHandler and URLHandler are bad names (for instances). Since we're stuck with camelCase, bad names are a fact of life. Sent from my iPhone > On May 19, 2016, at 11:56 AM, Pavel Kapinos via swift-evolution > wrote: > > Hi Brent, > > Thank you for you encouragement! Please join in to support it **now**! > > Cheers, > Pavel. > >>> On May 19, 2016, at 11:53 AM, Brent Royal-Gordon >>> wrote: >>> >>> SE-0005 "Better Translation of Objective-C APIs Into Swift Proposal” in >>> Proposed Solution # 6 "Lowercase values" suggests “to lowercase >>> non-prefixed values whenever they are imported” with an example of >>> URLHandler property becoming urlHandler. Being long time Cocoa developer, I >>> object to this particular example and would like to suggest to keep >>> capitalized any well known acronyms, like ASCII, PDF, URL etc. as they are >>> now in Cocoa. Thank you! >> >> I and others fought and lost this particular battle back when the guidelines >> were being drafted. Just be glad you didn't end up with uppercase rules >> calling for things like `UrlComponents`. >> >> -- >> Brent Royal-Gordon >> Architechies > > ___ > 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
