Re: [swift-evolution] Turning access control into SEP ;-)

[Andrey Fidrya via swift-evolution]

I use this access control model. As I usually split large classes into multiple 
files using extensions, marking members "fileprivate" or "private" initially is 
pointless.

Of course, "private" can be used for small classes which don't need to be 
split, but that would be inconsistent. Also the code looks tidy without being 
cluttered with "private" in every declaration.

It's too bad that compiler can't protect classes inside the same module from 
accessing implementation details of other classes using this approach, but I 
sacrificed this for freely splitting code between files. Imo, ideal access 
model for this coding style would be "type+extensions" visibility default with 
explicit "module" ("internal") and "public" modifiers.

Andrey

> On 17 Apr 2017, at 14:17, Tino Heth via swift-evolution 
>  wrote:
> 
> I don't remember the exact location, but there have been several 
> contributions from active members of the community who stated they would be 
> fine with just two levels of access control — but I haven't seen this 
> standpoint discussed at all.
> Most likely, that is because it contradicts the perceived spirit on 
> swift-evolution, but who knows, maybe this opinion isn't as isolated as we 
> think?
> To be honest, I don't expect that such a drastic simplification would be 
> seriously considered, but I think it's a good exercise to take such an 
> extreme perspective.
> 
> [If anyone would like to participate in this experiment, you may prefer to 
> skip the rest for now to avoid bias ;-) ]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> [personal results start here]
> 
> I don't need access control as a tool to enforce my opinion onto others, so 
> I'm not generally opposed to a compiler-orientated model, where access 
> limitation would only be used to allow better optimisation.
> 
> What I don't want to loose is a way to document intensions which helps users 
> of an API — but this could be something different than a compilation error 
> that tells me I'm trying to call a method that I'm not allowed to use.
> In my day to day routine, the language level actually isn't that important:
> When I work in an environment that is new to me, a method that is missing in 
> autocompletion is as protected as a private member, and it's similar for 
> overrides.
> So I would be fine with a set of annotations that are ignored by the 
> compiler, but used by the IDE. Actually, such an approach could have saved me 
> from stupid errors in the past, because the compiler only knows if I'm 
> allowed or forbidden to do something (anyone else ever had fun with 
> UITableView.didDeselectRowAtIndexPath? Alphabetical order is a really 
> inconvenient sometimes, and there is no way for the compiler to detect such 
> problems reliably).
> 
> ___
> 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] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Andrey Fidrya via swift-evolution]

> On 7 Apr 2017, at 07:57, Charlie Monroe via swift-evolution 
>  wrote:
> 
> -1 for reasons I've previously expressed in the discussions:
> 
> - It encourages everything to be stuffed in one file.
> - It doesn't actually solve anything as the new private is very close to 
> fileprivate, while abolishing private as truly scoped - which is a tool I use 
> on regular basis.
> 
> Simply as long as it's file-based, it's not a solution, it's just another 
> attempt to satisfy some part of the community. I'm not saying that the 
> current access levels are perfect, but I still believe the way to go is to 
> either use submodules, and/or introducing the concept of "protected" members.

+1 to the proposal.

How will submodules discourage stuffing everything into one file?
I can only think of creating a submodule per each class which doesn't look like 
a good solution.

I think this proposal is a step in the right direction. 'private' becomes 
type-based
and the only thing left to do is extending it to extensions in the module in 
the future.

Andrey

>> On Apr 7, 2017, at 1:10 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0169 "Improve Interaction Between private Declarations and 
>> Extensions" begins now and runs through April 11, 2017. The proposal is 
>> available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
>>  
>> 
>> Reply text
>> Other replies
>>  
>> What
>>  goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Andrey Fidrya via swift-evolution]

> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> I strongly prefer that “private” should mean “visible in the current file”.
> I am ambivalent between eliminating the scoped access level or renaming it 
> “scoped”, as long as “private” once more denotes file-level visibility.

Imo opinions are split 50/50 on whether access levels should be file based or 
type based, it's endless debate.
What are the downsides of covering both cases? I.e. making private "visible in 
the current file and type extensions".
This concept is not that hard to teach and doesn't require complex and 
syntactically verbose access level systems.

Andrey

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

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

[Andrey Fidrya via swift-evolution]

Hi Ankit,

I like the proposal very much. One question about SystemPackageProvider:

Sometimes it's neccessary to pass options to brew or apt-get, for example:
brew install libxml2 --with-python

Should they be added to package name or have a separate field? Adding the field 
in the future will break compatibility.

let package = Package(
providers: [
.brew(["libxml2 --with-python"]),
]
)

Another thing which comes to mind is a human-readable description field which 
could be helpful in some situations. I.e. "don't forget to generate a private 
key by running XXX". I think of something like this:

let package = Package(
providers: [
.brew([
  "openssl",
  SystemPackage(name: "libxml2", options: "--with-python", description: 
"")
]),
]
)

Regards,
Andrey



> On 14 Mar 2017, at 19:29, Rick Ballard via swift-build-dev 
>  wrote:
> 
> Proposal link:
> >  
> > https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md
> >  
> > 
> 
> Thanks for this feedback. We'll revise it to "from:".
> 
> Since we're still making minor revisions to this proposal, I'm going to 
> extend the review period by another day to make sure we don't have any other 
> important feedback pending.
> 
>   - Rick
> 
>> On Mar 14, 2017, at 12:28 AM, David Hart > > wrote:
>> 
>> Yep, after does sound confusing. I prefer from.
>> 
>>> On 14 Mar 2017, at 08:22, Ankit Aggarwal via swift-evolution 
>>> > wrote:
>>> 
>>> Hi,
>>> 
 – Dave Sweeris' point about this reading wrong in English as 
 .upToNextMajor("x.y.z") (vs. of "x.y.z".upToNextMajor) makes sense to us 
 too. As a result, we're going to clarify this by changing it to 
 .upToNextMajor(after:"x.y.z") and .upToNextMinor(after:"x.y.z").
>>> 
>>> 
>>> The "after" in .upToNextMajor(after: "x.y.z") sounds like we're going to 
>>> pick the version after `x.y.z`, for e.g. `x.y.(z+1)`, and go upto the next 
>>> major version. I think we should use `from` instead of `after`, which is 
>>> more clear IMO. It also feels like `after` and `from` (in shorthand) do 
>>> different things, and if we use `form`, it will also be reasonable to 
>>> assume that the `.package(url:from:)` is a shorthand form.
>>> 
>>> - Ankit
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-build-dev mailing list
> swift-build-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev

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

Re: [swift-evolution] [Draft] Fix Private Access Levels

[Andrey Fidrya via swift-evolution]

> In the previous very long thread, many people acknowledged that type + its 
> extensions private was too complex for its own good. Do you have arguments 
> against that? And even if it was proposed, I think many people would be very 
> opposed to keeping scoped in that case. There would be too little difference 
> between the two to be worth it.

I've been following that thread. Yes, I'll try to present them:

For example, I had to split this class into multiple files using extensions:
https://github.com/smud/Smud/blob/master/Sources/Smud/AreaFormatParser/AreaFormatParser.swift
 

I had to remove 'private' modifier from all variables and functions. Now class 
implementation details are exposed to the entire module. 'Fileprivate' was of 
no use in this situation. If there was an ability to mark them as `private to 
type + extensions`, I would use this access level instead. In fact, in 99% of 
use cases I needed that exact behavior and not 'internal to module', so I also 
proposed making it the default.

In other words, current visibility system doesn't work for my coding style 
(splitting classes into multiple files), nor it will work after rolling back 
private behavior. It could become useful if the concept could be exteded to 
mean "fileprivate + its extensions private". It would allow protecting other 
classes in the module from accessing implementation details of the current 
class. It's sad that many people are opposed to this concept.

On separate 'scoped' access, I agree that it may be redundant.

To summarize, I propose reverting "private" to mean "fileprivate" but extending 
it to extensions as well. This way both coding styles could be used: putting 
everything in a single huge file or splitting the class into multiple files or 
mixing these approaches. Ideally, I think it should be the default access level 
leaving only "public" and "internal" keywords to be set explicitly.

Regards,
Andrey



> On 21 Feb 2017, at 15:17, David Hart  wrote:
> 
>> 
>> On 21 Feb 2017, at 12:44, Andrey Fidrya > > wrote:
>> 
>> >Alternatives Considered:
>> >2. Deprecate fileprivate and modify the semantics of private to include 
>> >same-type extension scopes in the same module.
>> 
>> Imho, this is a better alternative.
>> 
>> I rarely implement class extensions in the same file. Most often they have 
>> their own files, like
>> MyClass+Search.swift
>> MyClass+SomethingElse.swift
>> 
>> Even in cases where implementing them in the same file makes sense, I'm not 
>> using current fileprivate modifier on variables because if I later have to 
>> implement an extension in a different file, I'll have to remove all these 
>> modifiers.
>> 
>> 
>> Also, I don't think internal is a good default choice... Even if private is 
>> changed back to mean "file private" or "class private", it will add a lot of 
>> visual noise... For proper access limitation, basically everything has to be 
>> marked "private". Compare:
>> 
>> class C {
>>   var a = 1
>>   var b = 2
>>   func f() { } 
>> }
>> 
>> to:
>> 
>> class C {
>>   private var a = 1
>>   private var b = 2
>>   private func f() { etc }
>> }
>> 
>> 
>> Also, in classes inheritance is denied by default, but variables have more 
>> open 'internal' access level by default.
>> It looks like an inconcistency to me. Users have to explicitly allow 
>> inheritance, but disallow access to variables.
>> 
>> 
>> +1 to the arguments about not mixing concepts (file or scope/type based). 
>> Personally I'd prefer scope/type only.
>> Also, fileprivate access doesn't play well with playgrounds and makes 
>> rearranging code harder.
>> 
>> 
>> If redesigning this from scratch, I'm thinking of this design:
>> 1. scoped (works like the current private)
>> 2. private (to the class + it's extensions inside the module) - and making 
>> it the default
>> 3. internal (to the module). Should be set only on variables where it's 
>> really needed (will be rarely used).
> 
> In the previous very long thread, many people acknowledged that type + its 
> extensions private was too complex for its own good. Do you have arguments 
> against that? And even if it was proposed, I think many people would be very 
> opposed to keeping scoped in that case. There would be too little difference 
> between the two to be worth it.
> 
>> One more argument for adding "scoped" access level:
>> if it will be allowed to declare variables in extensions of the same module 
>> in the future, having "scoped" would be very convenient as there can be 
>> multiple extensions in the same file.
>> 
>> 
>> Regards,
>> Andrey
>> 
>> 
>> 
>>> On 21 Feb 2017, at 09:58, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> Hello list,
>>> 
>>> Matthew Johnson and I have been putting our proposals together towards a 

Re: [swift-evolution] [Draft] Fix Private Access Levels

[Andrey Fidrya via swift-evolution]

>Alternatives Considered:
>2. Deprecate fileprivate and modify the semantics of private to include 
>same-type extension scopes in the same module.

Imho, this is a better alternative.

I rarely implement class extensions in the same file. Most often they have 
their own files, like
MyClass+Search.swift
MyClass+SomethingElse.swift

Even in cases where implementing them in the same file makes sense, I'm not 
using current fileprivate modifier on variables because if I later have to 
implement an extension in a different file, I'll have to remove all these 
modifiers.


Also, I don't think internal is a good default choice... Even if private is 
changed back to mean "file private" or "class private", it will add a lot of 
visual noise... For proper access limitation, basically everything has to be 
marked "private". Compare:

class C {
  var a = 1
  var b = 2
  func f() { } 
}

to:

class C {
  private var a = 1
  private var b = 2
  private func f() { etc }
}


Also, in classes inheritance is denied by default, but variables have more open 
'internal' access level by default.
It looks like an inconcistency to me. Users have to explicitly allow 
inheritance, but disallow access to variables.


+1 to the arguments about not mixing concepts (file or scope/type based). 
Personally I'd prefer scope/type only.
Also, fileprivate access doesn't play well with playgrounds and makes 
rearranging code harder.


If redesigning this from scratch, I'm thinking of this design:
1. scoped (works like the current private)
2. private (to the class + it's extensions inside the module) - and making it 
the default
3. internal (to the module). Should be set only on variables where it's really 
needed (will be rarely used).


One more argument for adding "scoped" access level:
if it will be allowed to declare variables in extensions of the same module in 
the future, having "scoped" would be very convenient as there can be multiple 
extensions in the same file.


Regards,
Andrey



> On 21 Feb 2017, at 09:58, David Hart via swift-evolution 
>  wrote:
> 
> Hello list,
> 
> Matthew Johnson and I have been putting our proposals together towards a 
> joint “let’s fix private access levels” proposal. As the community seems 
> quite divided on the issue, we offer two solutions in our proposal to let the 
> community debate and to let the core team make the final decision.
> 
> I’d like to concentrate this round of feedback on the quality of the 
> proposal, and not on the merits of Solution 1 or 2. thoughts?
> 
> https://github.com/hartbit/swift-evolution/blob/fix-private-access-levels/proposals/-fix-private-access-levels.md
>  
> 
> 
> David.
> 
> Fix Private Access Levels
> 
> Proposal: SE- 
> 
> Authors: David Hart , Matthew Johnson 
> 
> Review Manager: TBD
> Status: TBD
>  
> Introduction
> 
> This proposal presents the problems the came with the the access level 
> modifications in SE-0025 
> 
>  and presents two community driven solutions to fix them. As a consensus will 
> not easily emerge, this proposal will allow a last round of voting and let 
> the core team decide. Once that is done, this proposal will be ammended to 
> describe the chosen solution.
> 
>  
> Motivation
> 
> Since the release of Swift 3, the access level change of SE-0025 was met with 
> dissatisfaction by a substantial proportion of the general Swift community. 
> Before offering solutions, lets discuss how and why it can be viewed as 
> actiely harmful, the new requirement for syntax/API changes.
> 
>  
> Criticisms
>  of SE-0025
> 
> There are two primary criticism that have been offered.
> 
> The first is that private is a "soft default" access modifier for restricting 
> access within a file. Scoped access is not a good behavior for a "soft 
> default" because it is extremely common to use several extensions within a 
> file. A "soft default" (and therefore private) should work well with this 
> idiom. It is fair to say that changing the behavior of private such that it 
> does not work well with extensions meets the criteria of actively harmful in 
> the sense that it subtly encourages overuse of scoped access control and 
> discourages the more reasonable default by giving it the awkward name 
> fileprivate.
> 
> The second is that Swift's system of access control is too complex. Many 
> people feel 

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

[Andrey Fidrya via swift-evolution]

Pyry,

> Let me put it differently: I still haven't seen, nor was I able to conceive 
> myself, a realistic example where `??` would cause problems.


An example of broken code from real project:

let allParameters: [String: Any?] =
 defaultParameters["sendMessage"] ?? [:] +
 parameters +
 ["chat_id": chat_id, "text": text]

I think that the precedence of ?? is counter-intuitive because it's mainly used 
as
nil-unwrapping operator and there are often multiple optionals in an expression.
It's too easy to make errors like this one:

let value = x ?? defaultX + y ?? defaultY
let value = x ?? (defaultX + y ?? defaultY)

Imho braces should be required in these expressions.

Even this expression is confusing and in my opinion would only benefit from
braces:
let value = x ?? defaultX + modifier

Also, low precedence of ?? is a source of confusion in other languages, for 
example:
http://www.codeproject.com/Tips/721145/Beware-The-null-coalescing-operator-is-low-in-the
 

but in C# this operator isn't used as often as in Swift, so it's not a major 
issue there.

Andrey


> On 08 Sep 2016, at 15:20, Pyry Jahkola via swift-evolution 
>  wrote:
> 
> Vladimir,
> 
> I don't disagree with you about bitwise operations (please read my email 
> again). I'm saying when it comes to `??`, we don't have the evidence 
> necessary for proposing a breaking change.
> 
>> On 08 Sep 2016, at 14:21, Vladimir.S > > wrote:
>> 
>> Why do you need to see some precedence (…) while this construction is so 
>> simple and obviously would be used often and *will* cause bugs. (…)
> 
> Let me put it differently: I still haven't seen, nor was I able to conceive 
> myself, a realistic example where `??` would cause problems.
> 
>>> The original motivation by Erica simply failed to compile (…)
>> 
>> Sorry, but you are just not right.
> 
> Let me remind you that the original motivation from Erica wasn't about which 
> way `foundIndex ?? lastIndex + 1` goes but about whether `let y = 5 + x ?? 2` 
> compiles at all.
> 
>> The code compiles without even warning:
>> 
>> let foundIndex : Int? = 1
>> let lastIndex = 2
>> 
>> let nextIndex = foundIndex ?? lastIndex + 1
> 
> It certainly does compile. But is it realistic? Look at the variable names: 
> does this code make any sense at all? What is `lastIndex`? What is `lastIndex 
> + 1`? Why not `things.endIndex`? Indeed, why not:
> 
> let foundIndex: Int? = things.index(of: something)
> let nextIndex = foundIndex.map { $0 + 1 } ?? things.endIndex
> 
> That said, I give you the benefit of the doubt – I still believe there can be 
> examples where `??` may be confusing. But without seeing any such examples 
> from the real world, I don't think we have a case for changing `??`.
> 
>> After I showed the code compiles, would you change your opinion?
> 
> No, not with these examples.
> 
> * * *
> 
> Finally:
> 
>> IMO the best solution (…) would be to require (…) parenthesis when operators 
>> from different groups are mixed in the same expression. IMO no need in 
>> complex rules to make Swift safer. I.e. when you have a = 10 + 5 * 10 - you 
>> don't need parenthesis, when you have a = b << 4  - also all is ok, but if 
>> you have a = b << 4 + 5 * 10 - you'll have a warning until add parenthesis 
>> to make your intention clear. (…)
> 
> Look, changing how `b << 4 + 5 * 10` is compiled is exactly what I was 
> proposing. With my changes, it would become a compiler error. IMO, it ought 
> to be parenthesised explicitly as either
> 
> (b << 4) + 5 * 10
> 
> or
> 
> b << (4 + 5 * 10)
> 
> depending on which one was intended.
> 
> — Pyry
> 
> ___
> 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] Thoughts on replacing \() with $() or some other symbol

[Andrey Fidrya via swift-evolution]

I think that introducing another escape character is not a good idea.
\() is consistent with \r \n etc.

And I'm not sure if $ is easier to type. '\' is a single keypress and is located
near Backspace & Enter.

$ is SHIFT+4 and is harder to type without looking at the keyboard.

Andrey


> On 22 Jun 2016, at 02:25, Brandon Knope via swift-evolution 
>  wrote:
> 
> How can it be unpersuasive? I can *show* you that keys that are easier to 
> type/reach exist for a large majority of user’s.
> 
> I am not saying it is a good idea or not to replace \, but to pretend that 
> there isn’t an inconvenience there is unfair when every other part of the 
> language is put under a magnifying glass for the sake of grammar, newbie 
> friendliness, or this or that, etc...
> 
> This is measurable…it just depends on whether it bothers people or not 
> enough. Most other things are based on opinion, but this *can* be based on 
> numbers and usability.
> This is something used by everyone. The usability cost is there and it is 
> real. Just because “well it is easy for me to type” does not mean that it is 
> ideal. It also doesn’t mean that the current choice is the wrong choice 
> either. But it still is important to discuss while we can.
> 
> And yes a keyboard IS only so big, but the range to that bigness can be 
> pretty… big.
> 
> Also, $ is not the only option. There are still far easier keys to type than 
> \.
> 
> Brandon
> 
>> On Jun 21, 2016, at 7:15 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Jun 21, 2016 at 6:08 PM, Brandon Knope via swift-evolution 
>> > wrote:
>> Actually… we can go pretty scientific on this sort of thing and heat map 
>> keyboard usage to get a better picture of how “usable” this is.
>> 
>> I pasted a file that contains seven \’s in it and heat mapped it at 
>> https://www.patrick-wied.at/projects/heatmap-keyboard/ 
>> 
>> 
>> Even *with* several \’s throughout my source file the majority of my key 
>> presses take place much closer to the $ key than the \ key.
>> 
>> I think we can all argue about what is clearer or not, but I think for the 
>> majority of us, the \ key is quite inconvenient compared to the keys around 
>> where we type the most.
>> 
>> I also ran several of iOS 10’s sample code through the heat map and continue 
>> to get pretty similar results: the \ is much further from the hottest part 
>> of the keyboard than the ones closer to where your hand usually rests.
>> 
>> Maybe this is flawed, but I think it is hard to argue that the \ is easy to 
>> type when there are far more usable alternatives.
>> 
>> I'm rather unpersuaded by this line of argument. The keyboard is only so 
>> big; it's a stretch to say that any key is less than absolutely usable. 
>> Moreover, \ is next the delete key, which I presume you use frequently and 
>> find no difficulty in reaching.
>> 
>> You know what *is* unusable though? Try finding the $ key on an 
>> international keyboard.
>>  
>> Brandon
>> 
>> 
>> 
>>> On Jun 21, 2016, at 6:10 PM, Daniel Resnick via swift-evolution 
>>> > wrote:
>>> 
>>> I also disagree for the same reasons that Gwynne and Brent mentioned: I 
>>> find '\(...)' easy to read, fine to type, and consistent with other string 
>>> escaping syntax.
>>> 
>>> On Tue, Jun 21, 2016 at 3:55 PM, Brent Royal-Gordon via swift-evolution 
>>> > wrote:
>>> > I find that typing \(var) is very disruptive to my typing flow. The more 
>>> > I code in Swift, the more I like it, but every time I'm coding and then 
>>> > have to hiccup while typing \ then ( causes me to be annoyed. I know, 
>>> > it's minor, but it isn't a key combination that flows quickly.
>>> >
>>> > I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps 
>>> > @() to go along with other uses of @ throughout the language.
>>> 
>>> Even though I'm used to Perl's and Ruby's interpolation syntaxes, I 
>>> immediately liked `\(…)`. It's parsimonious: Rather than taking a third 
>>> character (besides \ and ") to mean something special in a string literal, 
>>> it reuses one of the existing ones. There's no need to escape a character 
>>> you wouldn't otherwise have to touch, or to think of another character as 
>>> "magical" in a string. It fits nicely with the rest of the syntax, with `\` 
>>> indicating a special construct and then `()` delimiting an expression, just 
>>> as they do elsewhere in the language. It's an elegant solution to a problem 
>>> traditionally solved inelegantly. It's very Swifty in that way.
>>> 
>>> > A shifted key, like $ or @, followed by another shifted key like (, 
>>> > allows for a much faster flow and they are much closer to the home keys 
>>> > than \ which is nearly as 

[swift-evolution] Nil coalescing operator precedence

[Andrey Fidrya via swift-evolution]

Nil coalescing operator has very low precedence and it's very easy to forget 
the parentheses.
It's tempting to write something like this:

let result = v1 ?? 0 + v2 ?? 0

Which will resolve to

let result = v1 ?? (0 + v2 ?? 0)

An example of incorrect code from real project which went unnoticed for some 
time:

let allParameters: [String: Any?] =
  defaultParameters["sendMessage"] ?? [:] +
  parameters +
  ["chat_id": chat_id, "text": text]

Unlike ternary operator I can hardly think of a case when someone would want to 
use ?? in expression like:
a + b ?? c + d meaning (a + b) ?? (c + d) 

This seems to be a source of errors in other languages as well, for example:
http://www.codeproject.com/Tips/721145/Beware-The-null-coalescing-operator-is-low-in-the

I propose to consider raising it's precedence or requiring parentheses if ?? is 
used with multiple statements.

--
Andrey Fidrya

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