Re: [swift-evolution] constant var
What are you going to do about this then?
func thirdFunc() {
self.myDict.removeAll()
}
Is this ok or not? Is it really different from `anotherFunc`?
On Thu, Dec 14, 2017 at 10:52 AM, Inder Kumar Rathore . via swift-evolution
wrote:
> class MyClass {
>
> private var myDict = [String : String]()
>
>
>
> func addMemebr() {
>
> self.myDict["key"] = "value" // Ok for me
>
> }
>
>
>
> func anotherFunc() {
>
> self.myDict = [String : String]() // Not okay for me, I don't want
> any code to do this within the class
>
> }
>
> }
>
> On Tue, Dec 12, 2017 at 10:28 PM, Joe Groff wrote:
>
>>
>>
>> > On Dec 11, 2017, at 11:34 PM, Inder Kumar Rathore . via swift-evolution
>> wrote:
>> >
>> > Hi All,
>> > Today I was writing code and faced a situation where I need to make a
>> instance variable a const i.e. it shouldn't accept new values from anywhere
>> but the problem is that I want it's content to be mutable.
>> >
>> > e.g.
>> >
>> > class MyClass {
>> > var myDict = [String : String]()
>> > }
>>
>> You can do this by making the setter private:
>>
>> class MyClass {
>> private(set) var myDict = [String: String]()
>> }
>>
>> This will allow declarations inside the MyClass definition to modify
>> myDict, but not code outside the class definition.
>>
>> -Joe
>>
>>
>
>
> --
> Best regards,
> Inder Kumar Rathore
>
> ___
> 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] Optional Argument Chaining
On Tue, Dec 12, 2017 at 12:42 AM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:
>
> I think it gets confusing when you have multiple levels of nested
> expressions, eg
>
> foo(bar(x?)) + y?
>
> Slava
>
I'm not sure we need to optimize much for complicated nested examples, as I
don't think this is something that will happen a lot in practice. I imagine
the most common scenario will be a single call with one or more arguments.
Having said that, we did receive 2 different reasonable answers on what the
evaluation order would be for:
f(a(), b?)
(1) It desugars to:
if let someB = b {
f(a(), someB)
}
So a() doesn't get called if b is nil.
(2) "If you were to write this logic out by hand then you would
short-circuit it and this is analogous to current chaining behaviour so to
me evaluating left to right (as Swift usually does) and stopping at the
first failed unwrap would make sense"
So a() gets called if b is nil.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
I think this distills the fears of some of the people that are against this proposal. To paraphrase, it is the fear that the dynamic type barbarians will come and pillage our villages. I on the other hand would welcome this highly hypothetical sub community. I would also welcome an obfuscated swift sub community, a non-ascii names sub community and any other weird sub community. I mean, why not? They are not going to affect my code or the libraries I use. Why not let them exist? What's with the elitism? On Fri, Dec 8, 2017 at 4:09 AM, Letanyan Arumugam via swift-evolution < swift-evolution@swift.org> wrote: > Okay I’ll concede and hope that a sub community, who are forced to use > Swift because of the success of this proposal and others to follow, doesn’t > form creating their own separate design patterns and beliefs :) > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
Apologies, I may have misunderstood you. What I wanted to say is that I see no problem allowing "dangerous" stuff that may be abused. What we shouldn't allow is features that are bug-prone, but this proposal is not that. On Wed, Dec 6, 2017 at 10:48 AM, Tino Heth <2...@gmx.de> wrote: > > During the discussion, people emphasized that dynamic features would be >> useful for more than Python interop, so if PyVal is the only way to get >> those benefits… I have no fear of JS-Bridges utilizing Python, or >> JSON-libraries build on top of PyVal — I just said that I don’t think it’s >> possible to prevent all abuses (adding restrictions might even cause abuse). >> >> > So what if they do this highly theoretical thing? Is this going to be a > superior way of programming? If yes, then let's all do it! If not, then a > superior solution will eventually emerge. Are you afraid that the community > will be "tainted" by bad code? That Foundation will be rewritten with > PyVals? And then you will be forced to write in PyVals too? What's the > issue here? > > What’s wrong with my formulation when I write „I have no fear“ so that > there are questions if I’m afraid afterwards? ;-) > Once again: I just said that the proposed restriction won’t be able to > prevent all abuse, which was claimed in an older post. > So I“m so un-afraid, I’d even prefer the more „dangerous“ (I don’t think > so) variant without artificial restrictions. > ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
On Tue, Dec 5, 2017 at 6:56 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > No specific concerns, but I’m pretty sure developers writing real code > will come up with ideas more bizarre than anything I can think of as an > example. > > During the discussion, people emphasized that dynamic features would be > useful for more than Python interop, so if PyVal is the only way to get > those benefits… I have no fear of JS-Bridges utilizing Python, or > JSON-libraries build on top of PyVal — I just said that I don’t think it’s > possible to prevent all abuses (adding restrictions might even cause abuse). > > So what if they do this highly theoretical thing? Is this going to be a superior way of programming? If yes, then let's all do it! If not, then a superior solution will eventually emerge. Are you afraid that the community will be "tainted" by bad code? That Foundation will be rewritten with PyVals? And then you will be forced to write in PyVals too? What's the issue here? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types
On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > Some people are big fans of dynamic behavior and this feature will make it > much easier to write code in that style. They will do it without feeling > malicious or considering this to be abusive, considering it to be a > legitimate style preference. I wouldn’t be surprised to see people develop > mixins that implement the subscript using mirror and other future > reflection capabilities without considering that to be abusive (I would > almost be surprised if this *didn’t* happen). Requiring some kind of > usage site annotation would both discourage this and help anyone who walks > into a such a code base to understand what is going on. > I really don't understand this fear of metamorphosis. People could also be using emoji for all their variables. So what? Let them do it! Are you afraid that this kind of code will eventually become idomatic Swift and soon all the good 3rd party libraries will be written like this? If yes, that means that Swift has failed as a language, people really wanted another Javascript. If not, what's the harm? Maybe eventually people doing this will realize that "proper" Swift is better. Or not. Right now there are a lot of people writting Swift in an Objective-C style. e.g. using classes when they should have used structs, using inheritance when they should have used protocols. Should we add some language feature to stop them? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Large Proposal: Non-Standard Libraries
I think there are two ideas discussed in this thread at the same time. One is for a more extended standard library, that is developed and shipped as part of the language. This is similar to what Python, Go and other languages are doing. The second is for a more wide collection of packages, developed by 3rd parties and not included with the language. This is similar to npm, PyPI, etc. If I understood it correctly, the original proposal is about the first idea and I don't think an "open market" approach works well for this. As for what should be included, I find Go to be a nice example, that could be used as a starting point: https://golang.org/pkg/ To summarize, it includes: - archival and compression formats (tar, zip, gzip, ...) - a few data structures - cryptographic functions (including hashes and random numbers) - sqlite and basic database drivers support - various data encodings (CSV, XML, JSON, ...) - some stuff used internally by the go tools (AST trees, debugging symbols) - basic graphics and image support - basic text and HTML templates - math and bignums - networking and HTTP support (client and server) - OS support (including path handling, command line flags etc) - Miscellanous stuff like dates, unicode, IO, string parsing, testing, etc. Go considers all these packages part of the language and offers source compatibility guarantees for all of them. I find the availability of these packages and the fact that they are developed and maintained by the Go core team to be very powerful. We can debate what should be included and if these should be separate modules or not, but I think the key insight here is that they are a curated list of useful libraries that are developed and maintained together with the language. On Wed, Nov 8, 2017 at 9:37 PM, Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 8, 2017, at 4:54 AM, Karl Wagner wrote: > > On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > > FWIW, Ben Cohen and I have been talking about possibly using Swift > packages as a way to seed out experimental ideas for extensions to the > Standard Library. This would allow ideas to be trialed by real usage (a > complaint I’ve seen about some changes we’ve made to Swift in the past). > Users could build things on top of those libraries, knowing they are > available as packages, and if an API “graduates” to being part of the > Standard Library the user can then depend upon it being available there. > If it never graduates, however, the package remains around. > > > Yeah this is exactly the problem that the package manager is there to > solve, right? It’s supposed to make it ridiculously easy to integrate > libraries and manage your dependencies. > > The problem is that most people writing Swift code every day are doing it > to make graphical applications on iOS/macOS. SwiftPM doesn’t support those, > so if I want to test a library, it’s just a one-off thing that I play with > in a Playground. > > > I think that the best thing we could do to encourage people to write, use > and contribute to public libraries would be to improve the package manager. > SwiftPM is still basically a toy (or an interesting curiosity), until it > can actually be used in the projects most Swift devs get paid to work on > every day. Talking about it supporting a community is way premature; it’s > not even close to ready to taking on that responsibility, IMO. > > > I agree that the tooling support around SwiftPM is not sufficiently > advanced yet to support this for everybody. Further, I don’t think there > would be a need to preclude other ways to share libraries for this purpose, > even if the SwiftPM tooling support was more mature. > > The primary point I wanted to make was more about the model itself. I’d > prefer the community grow up a set of libraries that trialed and used > before focusing on prematurely baking them into the core Swift distribution. > > ___ > 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] Large Proposal: Non-Standard Libraries
This is a great idea. Enabling people to actually sell code could be game changing. On Wed, Nov 8, 2017 at 12:44 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > > On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution < > swift-evolution@swift.org> wrote: > > We could also figure out a way to possibly highlight these efforts to the > Swift community, maybe on swift-evolution or other means — but all with the > expectation that these libraries are not *necessarily* going to be > standardized as part of the core swift distribution. I don’t think that’s > all that bad either; not every library will make sense to incorporate into > the core Swift distribution (e.g., they are highly domain specific) but > still supporting their development would be beneficial to the community. > > > What I *really* want to see is a Code Store in Xcode (kind of like an app > store for Swift packages). Basically, you would hit “Add Package” in the > sidebar/menu and a sheet pops up where you can search for and view various > packages. You then hit an “Add” button in the sheet, and it would add the > package to your project. To remove a package you would select it and hit > delete. > > Selecting a package in the sidebar would let you set some settings (e.g. > select a specific version), and view documentation. Xcode would manage the > files for you behind the scenes. > > I know that is out of scope for Evolution, but I just wanted to mention > it, since it might help with the visibility issue. > > Thanks, > Jon > > ___ > 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] Adding Result to the Standard Library
Right, to me there is not a lot of value in adding Result as it exists in
AlamoFire. We will (eventually) use the Swift Package Manager for things
like this. The value would be in integrating it like Optionals. e.g. (using
a strawman symbol)
var x: Int‽ = 5
var y: Int‽ = anErrorValue
func foo() -> Int‽ { ... }
if let x = foo() {
// x is Int
} else {
// somehow access the error
}
guard let x = foo() else {
// Again somehow access the error
}
func bar() throws -> String { ... }
let x = try‽ bar() // x is String‽
let y = x! // y is String
// Possibly even make it throw? (just using a random symbol again)
let z = try x¡
On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:
> This is clearly a fine addition to the standard library; even Swift's
> Error Handling Rationale (https://github.com/apple/swift/blob/master/docs/
> ErrorHandlingRationale.rst) mentions such an addition
>
> What separates standard library types from other types is that they have
> language level support, and the wrapping and unwrapping syntax here could
> definitely benefit from it (`.unwrap()`--which should be `.unwrapped()`
> incidentally--is so much less elegant in comparison to `?` and `!` for
> optionals (not that `Result` should use the exact such syntax for a
> distinct operation)). It would be a shame to transpose a third-party
> `Result` to the standard library without considering if any such tweaks
> would substantially improve ergonomics, interconversion with Optional and
> throws, etc.
>
>
> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Swift-Evolution:
>> I’ve written a first draft of a proposal to add Result to the standard
>> library by directly porting the Result type used in Alamofire to the
>> standard library. I’d be happy to implement it (type and tests for free!)
>> if someone could point me to the right place to do so. I’m not including it
>> directly in this email, since it includes the full implementation and is
>> therefore quite long. (Discourse, please!)
>>
>> https://github.com/jshier/swift-evolution/blob/master/propos
>> als/0187-add-result-to-the-standard-library.md
>>
>>
>> Thanks,
>>
>> Jon Shier
>>
>>
>>
>> ___
>> 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] multi-line string literals.
To me the discussion about precision of multiline strings is missing the
point. The biggest use case of this would be when using swift in a more
script-like fashion. You just paste something, add a
.components(separatedBy: “\n”).map { something() } and you print the result.
If you need precision, localizations, etc, multiline strings don’t have too
much to offer. You could just use plain + with marginal overhead. Or use
resource files.
On Mon, Apr 3, 2017 at 11:18 PM, Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:
> Why would backslashes at the end of each line be a nice idea?
>
> Sent from my iPhone
>
> On Apr 3, 2017, at 2:44 PM, Paweł Wojtkowiak via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think that there's nothing wrong with two "tools" for the same task in
> this case. Multiline strings look better in the code and are easier to read
> and can serve many purposes. By reading different texts from swift dev team
> I feel like this is something the language was designed with in mind.
> They're also easier to type and it needn't neccessarily be a string
> presented to the user.
>
> Lets say I want a simple json literal for testing purposes - reading from
> a file takes much more effort comparing to inserting it directly in the
> code. Taking out every new line character makes it hard to read, and
> inserting quotes and pluses every line both needs extra effort and also
> decreases readability. Adding it as a multiline string would make a perfect
> solution for this to me.
>
> There are so many other cases where this could be useful too. I like how
> python has the """ and I think this would be a good direction to go,
> although this is true that python uses indentation in a different way, so I
> think backslashes at the end of each line would be a nice idea - this is
> still better than concatenating each line with " and +, and would have the
> least readability impact. Also, it could be treated as a literal and be
> evaluated at compile time.
>
> I just checked with -O and without and was surprised to find that `let x =
> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal
> "abcdefghi" in the generated assembly code. Maybe it's more difficult than
> it is in some other languages because of operator overloads and different
> kinds of text literals (strings, extended grapheme clusters, Unicode
> scalars)?
>
> Regardless of the reasons, a separate syntax isn't the right way to
> achieve this optimization—the compiler should just do it automatically.
> Like Ricardo, "multi-line string literals" should be reserved for string
> literals that include the newline characters that are used to break them up
> in source. The idea of supporting something like the Python example above
> just provides two ways to do the same thing, which I don't think we really
> need.
>
>
> On Mon, Apr 3, 2017 at 8:18 AM Ricardo Parada via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> I would think that the concatenation would get resolved at runtime,
>> unless the compiler gets smart about it. But either way I do not see it as
>> a problem. The reason is that I don't remember ever worrying about the
>> performance of concatenating a few lines of text. :-)
>>
>> Thanks
>>
>>
>> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev > com> wrote:
>>
>> To me a literal a single entity which is solved at compile time. The
>> concatenation is however resolved at runtime if I’m not mistaken here (it
>> might be optimized at compile time but I still would expect a function
>> executed a couple of times at runtime).
>>
>> Please correct me if I’m wrong here.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com) schrieb:
>>
>> How is that better than this?
>>
>> template = "This is the first line.\n" +
>> "This is the second line.\n" +
>> "This is the third line."
>>
>>
>> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It look prettier without the \n
>>
>> It's not laziness.
>>
>> I want my code to look pretty.
>>
>>
>> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev > com> wrote:
>>
>> What I was trying to say is that by automatically adding a new line
>> character does not provide any benefit except of being lazy to type \n.
>>
>> // In your model this would be equivalent
>> let s1 = "\n\n\n"
>> let s2 = """
>> " // However in my model this is an empty string and should be banned
>> "
>> """ // That's also an empty string, but it that case it indicates the
>> end of the multi lined string
>>
>> I dislike the tradeoff of precision for laziness.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 3. April 2017 um 16:29:44, Ricardo Parada (rpar...@mac.com) schrieb:
>>
>> By the way, the multi-line string should allow \n\n, or as many as you
>> may want to throw in there. I don't see a problem with th
Re: [swift-evolution] Code blocks and trailing closures
I think the word you are looking for is “confusing”, not “ambiguous”.
Nothing is ambiguous
about the code you wrote, but you could make an argument that you find it
confusing (since this is something subjective).
On Wed, Mar 15, 2017 at 12:35 PM, Rien via swift-evolution <
swift-evolution@swift.org> wrote:
> What does the following code fragment do?
>
> serverCert.write(to: certificateUrl) { showErrorInKeyWindow(message);
> return }
>
> The only possible answer is: I don’t know.
>
> The problem is finding out what the “return” statement will do.
>
> Without knowing if the {...} is a code block or a trailing closure it is
> impossible to know what the return statement will do. It will either end
> the closure or it will end the function that contains this code block.
>
> This could be disambiguated by using the same syntax as for lazy variables:
>
> serverCert.write(to: serverCertificateUrl) { showErrorInKeyWindow(message:
> message); return }()
>
> Now it is clear that the return statement will only terminate the
> (trailing) closure.
>
> A question to the educators on the list: Is this a real problem?
>
> Personally, I dislike this situation, but I am also ambivalent towards the
> solution I just described.
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
> ___
> 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: Replacement for FileHandle
I’m going OT here, but even though I understand your reasons, you need to acknowledge that for developers the rational thing to do is to not file radars at all. Any bug fix will get released at best a few months later and you can only actually take advantage of it a few years later (if you care about supporting older versions). More realistically we are talking 3-4 years of having to work around it (in the best cases). This is a lot of work (with almost zero feedback) for some far future benefit that probably will not even be relevant to you then. So to me, when an Apple developer asks me to file a radar, it feels like they are asking me to do their job. I’m sorry for the off-topic rant. On Thu, Feb 16, 2017 at 1:45 AM, Tony Parker via swift-evolution < swift-evolution@swift.org> wrote: > > On Feb 15, 2017, at 2:25 PM, Charles Srstka > wrote: > > On Feb 15, 2017, at 3:11 PM, Itai Ferber wrote: > > > FYI, Tony is the manager of the Foundation team. :) > We care very much about making sure that the experience of using our > framework is a positive one — the more Radars we get, the better we can > prioritize improving APIs that are not working as well as they could be for > our users. Even if the Radar gets duped to an existing one, thats one more > +1 for that Radar saying "this is a problem". > > Yeah I know, but it’s a frustrating experience, spending a half hour > writing a detailed bug report (sometimes with videos attached to > demonstrate the issue), just to effectively do the same thing as spending 5 > seconds to hit the +1 button on most issue trackers you come across. > > Especially since you never find out what happened to the original bug > report. You can see if it’s open or closed, but did they fix it in some > internal build? Did they decide it “behaves correctly?” Did somebody just > skim your report, and mistakenly attach it to some other, unrelated issue? > There’s no way to know. > > I will search for your old Radar, but in any case, please do file a new > one about this, and about any other issues you have, because we are indeed > listening. > > I was pretty sure I'd submitted something way, way back in the misty days > of yore, but I can’t find it. I’ve filed a couple of new ones: > rdar://30543037 and rdar://30543133. > > Charles > > > Thanks for filing these. > > Sometimes, for process reasons, we do indeed mark bugs as dupes of other > ones. Usually the polite thing to do is to dupe to the earliest filed one. > Sometimes this comes across with an appearance of not caring to the filer > of the new bug, but our intent is simply to consolidate the reports we have > so that we know that the issue is serious. > > We do not make API changes without going through a vigorous review > process, to avoid churn for the many clients above us. The flip side is > that this can take some time. I’m sure you understand that all software > engineering is about tradeoffs. > > All of that said, we’ll take a look at these and see what improvements we > can make here. As I said, I’m not a fan of exception-based API. > > - Tony > > > > ___ > 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] [pitch] Make exceptions visible in guard's else block
Hello all, I'm interested in a pattern to return failure, together with an
error
to explain why. I think that the "guard let x = x" discussion touched on
the issue,
but didn't really go in that direction.
Right now, optional and boolean results work nicely with guards, but you
only get
sucess/failure back. For example:
func foo() -> Int?
func bar() -> Bool
func baz(Int) -> Int?
guard
let a = foo(),
bar(),
let b = baz(a)
else {
// No information about what failed here
print("Something failed")
return
}
I see a lot of enum Result solutions being proposed, but they have the
fundamental
problem of not having access to the error inside guards. For example:
enum Result { case sucess(T), error(String) }
func foo() -> Result
guard case let .success(value) = foo() else {
// Result is .error but we have no access to the error message here
return
}
I think a solution to this problem could be to allow "guard let try"
statements
that make the error available inside the else statement. So you could write:
func foo() throws -> Int
func bar() -> Bool
func baz(Int) throws -> Int
guard
let a = try foo(),
bar(),
let b = try baz(a)
else {
// `error` is available here like in a catch block
print("Error: \(error.localizedDescription)")
return
}
A potential weirdness of this solution is that it appears indistinguishable
from
"guard let try?" (already available) if you are not interested in the error.
Thoughts?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
