I don’t know how C API is imported, btus INOUT parameter must be mutable, this
is a language artifact.
Am 16. Januar 2018 um 22:10:13, Rick Mann via swift-users
(swift-us...@swift.org) schrieb:
Is it not possible for Swift to treat C API const pointers as something that
can take let arguments
toggle() on a mutable Bool is good, though.
- Karl
On Fri, Jan 12, 2018 at 10:13 AM, Adrian Zubarev via swift-evolution
wrote:
I’m not sure if this would be considered or not, but I would like if the
negation operator `!` would fade out.
If this is ever going to a review then I’d suggest that we ad
gic.
That said, I can’t come up with a clearer name than “== false”. inverted()
isn’t helpful. toggle() on a mutable Bool is good, though.
- Karl
> On Fri, Jan 12, 2018 at 10:13 AM, Adrian Zubarev via swift-evolution
> wrote:
>> I’m not sure if this would be considered or not,
ode I end
up doing == false just for readability. That ! knows who to hide
himself too well :P
On Fri, Jan 12, 2018 at 10:13 AM, Adrian Zubarev via swift-evolution
wrote:
> I’m not sure if this would be considered or not, but I would like if the
> negation operator `!` wou
I’m not sure if this would be considered or not, but I would like if the
negation operator `!` would fade out.
If this is ever going to a review then I’d suggest that we add a pair of
functions, one mutating and the other non-mutating.
extension Bool {
mutating func invert() {
self = !sel
Well some of you guys have to wait a little longer, but I can already wish
everyone a happy new year from Germany. 🎉🎊🎆🎇
--
Adrian Zubarev
Sent with Airmail ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/li
Well again I don’t think we should disallow capturing the outer generic type
parameter just because you cannot use the protocol inside the outer type atm.,
you still can add a type-eraser. To be honest such usage of the existential is
not even a requirement for the outer type. On there other han
I disagree with some of your points. Do begin with, I don’t think we should
disallow capturing the generic type parameter, because I think there might be a
good way to prevent parameterization of nested protocols.
To me this only feels like a natural consequence of nesting protocols anyways.
To
ion of
evaluation order of arguments is a serious problem for the original idea.
On Dec 12, 2017, at 2:32 PM, Adrian Zubarev via swift-evolution
wrote:
I propose that we do not add a suffix ? to the arguments because it does not
really signal that the whole function may return an optional value. T
I propose that we do not add a suffix ? to the arguments because it does not
really signal that the whole function may return an optional value. This is
especially not convenient in a nested scenario like mentioned by others in
previous posts. Instead we should reuse the inifix ? on functions, s
I think it might be a good idea to reuse optional function syntax in this case.
I don’t think it would even break existing code with the rule I described in my
previous post. I mean, in the end the result of the whole function becomes
optional (only if it was non-optional before, or it simply st
This is an interesting example but I think the solution might be simple if we
try to desugar it.
// example
f(g()?, h()?, i(), j()?)?
// desugared
let/var someF: SomeType?
if let someG = g(), let someH = h(), let someJ = j() {
someF = f(someG, someH, i(), someJ)
} else {
someF = nil
}
F
its parameter, not just F:
protocol P {}
struct F: P {}
struct G: P {}
func foo(_ p: inout P) {
p = G()
}
var f = F()
foo(&f) // assigns a value of type G to a variable of type F
>From Jonathan
On Dec 10, 2017, at 12:51 AM, Adrian Zubarev via swift-evolution
wrote:
Hello Matthew,
Hello Matthew, I have more more question about the generalized supertype
constraints. Does the generalization also covers inout? I found a really
annoying case with inout.
protocol P {}
func foo(_ p: inout P) {
print(p)
}
struct F : P {}
var f = F()
foo(&f) // won't compile until we expl
I like it, but only if the API is symmetric. However this would require the
break existing API to make `firstIndex(where/of:)`.
One question:
Can we maybe add retroactively an extra parameter with a default value?
Something like: `func index(where predicate: (Element) throws -> Bool,
traverse
What happened to this? Should we revive this talk? I’d love to finally be able
to nest protocols in Swift 5 and clean up my code.
Am 18. Januar 2017 um 09:48:20, Slava Pestov via swift-evolution
(swift-evolution@swift.org) schrieb:
I left some review comments here:
https://github.com/apple/sw
to expected type 'Service'
} else {
manager.register(DefaultWikiService(), ofType: WikiService.self) //
Currently: error: in argument type 'WikiService.Protocol', 'WikiService' does
not conform to expected type 'Service'
}
If that's right, I'm also +1
In general this is more then welcome, so +1 for me.
However I have one question:
Could this allow support, or at least be a first step towards Swift allowing
the following behaviour?
```
extension MyProtocol where Self : SomeClass {
static func getSubtypes(ofType _: T.Type = T.self) ->
Hello Chris, I have some questions about this passage:
Before this proposal, the Swift language has two types that participate in call
syntax: functions and metatypes (for initialization). Neither of those may
conform to protocols at the moment, so this introduces no possible ambiguity
into the
That sounds great to me. I don’t see December as a promise, and as I already
mentioned in the other thread, that’s totally fine by me. I think it’s only
fair if I say that a little bit more transparency on what’s going on with the
forum is already enough for the community.
I’d say we should mig
Hello Ted, would you mind opening a new thread and post an update about the
forum and maybe answer a few minor questions like:
- what is currently planned?
- in which timeframe we *might* see the forum finally happening (don’t have to
be a promise)?
- what happens to old mailing lists? (I’d say p
Same here, but I wouldn’t care much if it were gone.
Am 7. November 2017 um 21:40:56, David Hart via swift-evolution
(swift-evolution@swift.org) schrieb:
Yeah, I use the first form constantly.
> On 6 Nov 2017, at 23:33, Slava Pestov via swift-evolution
> wrote:
>
> Hi all,
>
> Right now,
Just a quick question for clarification. What will happen to these? Do we have
to provide the default value ourselves?
class ViewController : UIViewController {
@IBOutlet weak var view1: UIView?
@IBOutlet weak var view2: UIView!
}
Am 6. November 2017 um 23:33:51, Slava Pestov via swif
To be fair, I would want to see the outcome of the `typed throws` discussion
first before moving the discussion about `Result` forward.
Am 3. November 2017 um 04:41:32, Chris Lattner via swift-evolution
(swift-evolution@swift.org) schrieb:
On Nov 2, 2017, at 11:08 AM, Jon Shier via swift-evo
You’re not really missing an other access modifier here. I assume you’re
speaking about a macOS/iOS app, right? Therefore the thing you’re really
missing is a full integration of SPM in Xcode macOS/iOS projects and
submodules. Then, and only then `internal` would really seem like the right
choi
I’d be happy if we’d get iOS support and submodules :)
Am 23. Oktober 2017 um 19:41:37, Jean-Christophe Pastant via swift-evolution
(swift-evolution@swift.org) schrieb:
Hi,
Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS supp
So you’re saying the core team _might_ consider a review if we’ve get a full
proposal + implementation in Swift 5 timeframe?
If yes, we only would need someone to implement my proposal. :)
Am 9. Oktober 2017 um 19:54:50, Jordan Rose via swift-evolution
(swift-evolution@swift.org) schrieb:
>
async is a keyword where as @discardableResult is an attribute. This pitch does
not include any advantages over the current form. In fact this will rather harm
the readbility because you no longer can nicely put the annotation above the
function and it won’t play well with other keywords like th
Was there any progress made on this? It almost feels like were not going to
move to a forum until Swift 6-7. Would be interesting to see a sign of progress
here. :)
Am 3. August 2017 um 23:14:16, Erica Sadun via swift-evolution
(swift-evolution@swift.org) schrieb:
When moving to a forum, the
Even I would personally want this, this request didn’t made into Swift 3, nor
in Swift 4 and is clearly out of scope for Swift 5.
You can read my proposal here which includes all areas where this could be
allowed:
https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_r
No please no, the ship is long sailed for this one. I wish I didn‘t messed up
my proposal last year and that we completely got rid of the access modifiers
before the `extension` keyword.
Huge -1
--
Adrian Zubarev
Sent with Airmail
Am 28. September 2017 um 19:44:25, James Valaitis via swi
I still would prefer ligature fonts (Fira-Code). All these complicated
characters might be good and so but remeber there are more than one keyboard
layout on this planet, some of those are far more complicated than the English
keyboard layout. Even I struggle sometimes with simple {} and [] beca
olution/blob/az-existentials/proposals/-enhanced-existentials.md.
Sent from my iPad
On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution
wrote:
It’s part of Generalized Existentials, but does not make it complete. I think
it would be worth adding more and more functionality to exi
Well I didn’t meant to say to spend time for something that will not even make
into a review. If we can have some clarification from the core team, we still
can decide if we’d tackle it or not. ;)
Am 21. August 2017 um 14:51:06, David Hart (da...@hartbit.com) schrieb:
On 21 Aug 2017, at 13:
It’s part of Generalized Existentials, but does not make it complete. I think
it would be worth adding more and more functionality to existentials every
year. We started first with reshaping the syntax. This year we added support
for classes. I think next year would be good to have where clause
Yes, `where` clause is welcome to typealises (including generic ones) and
existentials in general. I would love to help on such proposal. I think David
Hart is also interested in this one. (cc)
Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution
(swift-evolution@swift.org) schr
Wasn’t Joe Groff and Daniel Duan proposing anonymous enum cases in some of the
early draft of the ‘Normalize Enum Case Representation’ proposal?
Maybe it’s time to revive that topic.
Matthew Johnson has also some interesting ideas in hist gist:
https://gist.github.com/anandabits/5b7f8e3836387e8
, no?
On Thu, Aug 17, 2017 at 04:47 Jonathan Hull via swift-evolution
wrote:
+1
On Aug 17, 2017, at 2:38 AM, Adrian Zubarev via swift-evolution
wrote:
This is a small pitch which I will abandon if there is not much appetite for
such improvement. ;)
I would like to propose an improvement to an
This is a small pitch which I will abandon if there is not much appetite for
such improvement. ;)
I would like to propose an improvement to an initializer of all collection
types that provide: init(repeating repeatedValue: Element, count: Int).
This change is meant to support reference type ini
Okay I came to the conclusion that this won’t work that easily. Here is my
reasoning why I think that way. If one assume for a second that one day we
might have value sub typing - yes not now and not in the next Swift version,
but hear me out please - we will come back and discuss the alignment
I think this design does not avoid you writing something like `private enum Foo
{ default ... }`, which is redudant as Jordan already pointed out in his
previous post, nor does it have a consistent way of declaration:
enum Foo {
case abc
case def
default
}
enum Foo {
case abc
default
to:da...@hartbit.com)) schrieb:
>
>
> > On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution
> > mailto:swift-evolution@swift.org)> wrote:
> >
> > Hi there, I don’t mean to be rude or something, nor do I want to hold the
> > review process up from
Hi there, I don’t mean to be rude or something, nor do I want to hold the
review process up from succeeding, but where is the branch with the
implementation?
Quote:
The proposal phase for Swift 4 is now officially over
I hope that the core team does not pick proposals they like, for instance th
I’d very much in favour of a consistent access modifiers across the whole
language and eliminate exclusive `open`. `open/public` protocols are more than
welcome. Plus it’s already has been said that Swift will potentially support
subtyping for value type in some future, where we’ll yet again wou
Hi Jordan, is that only me or haven't you metioned the default should be
applied to all new enums? Personally I'd say that 'closed' should be the
default and the 'open' enum would require an extra keyword.
Now about the keyword itself. Here are two keywords that IMHO nail their
behavior down
Thank you for the kind updates Ted. However I already feel the negative impact
because of the last restriction. I also would like to point out that,
personally I think until the swift-evolution is not moved to a forum this will
only create a great wall between proposal authors and people that ar
I’m not sure how I would feel about this. To be honest I’d avoid such
additional changes from the stdlib, because they really don’t belong there.
Instead some `Math` module/package would be a better fit than clustering
everything into stdlib until we end up also adding UI stuff.
Furthermore, I
We had some really really long talks about that before. Search for something
like `AnyValue` and `ValueSemantics`. ;)
--
Adrian Zubarev
Sent with Airmail
Am 31. Juli 2017 um 07:33:36, Daryle Walker via swift-evolution
(swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:
>
This is intended because () is confusing. If you need that back, simply add
(Void).
For more information read this proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md
--
Adrian Zubarev
Sent with Airmail
Am 28. Juli 2017 um
lt;0 … 1>@Double = …
Obviously none of them are visually pleasant to my eyes.
Am 23. Juli 2017 um 17:45:57, Taylor Swift (kelvin1...@gmail.com) schrieb:
On Sun, Jul 23, 2017 at 5:29 AM, Adrian Zubarev via swift-evolution
wrote:
I wanted to read the proposal, but skipped it as soon as I’
I wanted to read the proposal, but skipped it as soon as I’ve seen the syntax.
From the esthetic point of you the proposed syntax is really ugly. Again I’m
not speaking against the feature in general, nor against any of the technical
benefits fixed-size array will provide to us. I simply dislike
I only had a quick glance but I quickly noticed that there were quite a lot
cases which didn’t require a trailing new line, but if we’d revert this
decision would require a trailing \ over and over.
That would make the simplest multi-line string literal not that simple anymore:
"""
abc
""" == "
be c:\\ anyways. If you than would want to break your line then
you’ll end up with c:\\\ which might look ugly but it’s a consequence of using
\ for our main purpose.
--
Adrian Zubarev
Sent with Airmail
On 13. July 2017 at 13:28:48, Vladimir.S (sva...@gmail.com) wrote:
On 13.07.2017 9:24, Adr
One more thing I wanted to add.
I would remove the restriction of
An escape character at the end of the last line of a literal is an error, as no
newlines follow.
from this proposal and allow the trailing backslash in the last line which
won’t do harm to anything. The idea behind this is that o
Can you please elaborate?
—
In general I, as one of the co-authors, am for this additional change. However,
personally I would be against adding the new line escaping feature to the
single double-quote string literal, because it will create asymmetry.
For instance in a future proposal it’s lik
true.whenTrue(execute: test)
A syntactical convenience feature should not disable explicitness!
--
Adrian Zubarev
Sent with Airmail
Am 1. Juli 2017 um 19:46:55, jaden.gel...@gmail.com (jaden.gel...@gmail.com)
schrieb:
On Jun 30, 2017, at 1:48 AM, Adrian Zubarev via swift-evolution
w
I expect #1 here
// () -> Void?
true.whenTrue(execute: test)
A syntactical convenience feature should not disable explicitness!
--
Adrian Zubarev
Sent with Airmail
Am 1. Juli 2017 um 19:46:55, jaden.gel...@gmail.com (jaden.gel...@gmail.com)
schrieb:
On Jun 30, 2017, at 1:48 AM, Adrian Zu
What are you proposing here, I don’t get it?! What role should .Protocol play?
.Protocol is an ugly hack in Swift which should be removed anyway. It does more
harm than good.
Our revised proposal was deferred from Swift 4:
https://github.com/DevAndArtist/swift-evolution/blob/refactor_existentia
+1 Well summarized.
The !! operator feels more like:
func !! (optional: T?, errorMessage: String) -> T {
return optional ?? fatalError(errorMessage)
}
Which is totally unnecessary.
--
Adrian Zubarev
Sent with Airmail
Am 30. Juni 2017 um 07:24:04, Brent Royal-Gordon via swift-evolution
(s
first point.
I hope I don’t come off as too harsh. It’s just a little shocking to me that
we accept the code in the linked SR.
~Robert Widmann
On Jun 24, 2017, at 9:10 AM, Adrian Zubarev via swift-evolution
wrote:
Hello folks,
Here is a quick and straightforward pitch about @autoclosure
quires a fundamental change to the language.
- Pushing forward on this proposal does not in any way reflect on adopting the
still-desirable `Never` bottom type.
On Jun 28, 2017, at 12:42 PM, Tony Allevato via swift-evolution
wrote:
On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong wrote:
On Jun 28, 2
levato via swift-evolution
wrote:
On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong wrote:
On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution
wrote:
Well the main debate is that, we all want early access to a feature that will
be part of Swift as soon as `Never` becomes the
Jun 28, 2017 at 11:15 AM Dave DeLong wrote:
On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution
wrote:
Well the main debate is that, we all want early access to a feature that will
be part of Swift as soon as `Never` becomes the bottom type. When this happens
the `??` w
Well the main debate is that, we all want early access to a feature that will
be part of Swift as soon as `Never` becomes the bottom type. When this happens
the `??` will automatically support the pitched behavior. Until then if we all
agree that we should add it now in a way that will not break
How about?
public func ?? (optional: T?, noreturnOrError: @autoclosure () throws ->
Never) rethrows -> T {
switch optional {
case .some(let value):
return value
case .none:
try noreturnOrError()
}
}
--
Adrian Zubarev
Sent with Airmail
Am 27. Juni 2017 um 21:54:
Can’t we simply overload ?? to support @autoclosure () -> Never now and remove
that overload when Never is the bottom type? Syntactically it would look and do
the same.
--
Adrian Zubarev
Sent with Airmail
Am 27. Juni 2017 um 21:52:01, Matthew Johnson via swift-evolution
(swift-evolution@swi
+1 I had a slightly different implementation.
https://gist.github.com/DevAndArtist/dad641ee833e60b02fd1db2dbb488c6a
//
// UnwrapOrTrap.swift
//
infix operator ?! : NilCoalescingPrecedence
/// Performs a nil-coalescing operation, returning the wrapped value of an
/// `Optional` instance or uses t
Hi Ben,
Is there any difference to this altered version of your example?
func foo(_ test: () -> Int) {
print(#function, test())
}
func bar(_ test: () -> Int) {
foo(test)
}
func baz(_ test: @autoclosure () -> Int) {
bar(test)
}
baz(42)
It looks exactly the same to me. After the pitc
er
closure.
What exactly will `$0` refer to?
On Jun 24, 2017, at 7:10 PM, Adrian Zubarev via swift-evolution
wrote:
Hello folks,
Here is a quick and straightforward pitch about @autoclosure. Currently the
attribute indicates that the caller has to pass an expression so that the
braces can be omitt
Hello folks,
Here is a quick and straightforward pitch about @autoclosure. Currently the
attribute indicates that the caller has to pass an expression so that the
braces can be omitted. This is a convenient behavior only, but it also has it’s
shortcomings.
I would like to propose an extension
I can only agree here, the language suffers from shortcuts like that. Same goes
for access modifier on extensions, or `indirect` before enums and as already
mentioned before me labeled tuple destructuring.
--
Adrian Zubarev
Sent with Airmail
Am 17. Juni 2017 um 18:09:50, Matthew Johnson via sw
I’ve already mentioned this in this thread. This is one of the missing features
from the generics manifesto, however it’s (almost) a syntactic sugar only. It
means that if we would enforce default in Swift 4, then having default
implementation directly inside protocols would be really a syntacti
I’d support the breaking change here to allow the language to evolve properly
instead of introducing halve baked opt-ins and workarounds for issues that
totally deserve a fix. The first thought that I had when reading the proposal
the first time was, that extend does not add any benefit to the l
I like the idea of fixing this area of the language and I’m happy to see others
already pointed out that extend could be implicit and does not need to be
introduced at all, where default would become necessary for protocol default
implementations.
If I’m not mistaken this _can_ be an improvemen
If the `indirect` confusion becomes real, I'd suggest getting rid of `indirect
enum` and using `indirect case` instead.
On Jun 11, 2017, at 11:05 AM, Adrian Zubarev via swift-evolution
wrote:
The proposal is looking good to me. :) It will also enable easy support for
custom views usin
fault access modifier from `internal` to whatever
I specify? That's just confusing, reduces readability and the syntactic gain is
marginal at best.
If the `indirect` confusion becomes real, I'd suggest getting rid of `indirect
enum` and using `indirect case` instead.
On Jun 11, 2017, at 11:
7;s just confusing, reduces readability and the syntactic gain is
marginal at best.
If the `indirect` confusion becomes real, I'd suggest getting rid of `indirect
enum` and using `indirect case` instead.
On Jun 11, 2017, at 11:05 AM, Adrian Zubarev via swift-evolution
wrote:
The proposal
syntactic gain is
marginal at best.
If the `indirect` confusion becomes real, I'd suggest getting rid of `indirect
enum` and using `indirect case` instead.
On Jun 11, 2017, at 11:05 AM, Adrian Zubarev via swift-evolution
wrote:
The proposal is looking good to me. :) It will also enable e
The proposal is looking good to me. :) It will also enable easy support for
custom views using XIBs in iOS development without unnecessary view nesting.
For instance the function from this example
https://stackoverflow.com/a/43123783/4572536 could be used directly inside an
init:
class MyView
reference type along classes) would be eligible for storing by
`weak/unowned` reference.
On Jun 10, 2017, at 10:39 PM, Adrian Zubarev via swift-evolution
wrote:
Hi Matthew,
Thank you for the hint. Indeed, at first glance your proposal is very similar
to my thinking. I’ll try to dive deeper into yo
think this behavior has to stay the same with the addition of closures (being
the other reference type along classes) would be eligible for storing by
`weak/unowned` reference.
On Jun 10, 2017, at 10:39 PM, Adrian Zubarev via swift-evolution
wrote:
Hi Matthew,
Thank you for the hint. Indeed,
/032478.html.
On Jun 10, 2017, at 12:29 PM, Adrian Zubarev via swift-evolution
wrote:
Hello Evolution,
I’d like to pitch a new idea and see where it would go. Recently I tapped into
a small trap and just now realized that even that non-escaping should have been
the default for closures (SE–0103
Hello Evolution,
I’d like to pitch a new idea and see where it would go. Recently I tapped into
a small trap and just now realized that even that non-escaping should have been
the default for closures (SE–0103) there is an exception for that. Apparently
generics don’t follow that rule and a clo
via swift-evolution
wrote:
Well please no:
let fn2: ((Int, Int)) -> Void = { lhs, rhs in }
Instead use destructuring sugar pitched by Chris Lattner on the other thread:
let fn2: ((Int, Int)) -> Void = { ((lhs, rhs)) in }
I think this suggestion is better than the status quo. I'
Well I was referring to the title of (1) not to the addition it creates with
failable initializers, which I guess is fine by me, but I’d need a more
detailed proposal or draft to provide better feedback though.
--
Adrian Zubarev
Sent with Airmail
Am 8. Juni 2017 um 17:51:28, Gor Gyolchanyan
Isn’t 1 und 2.1 almost the same stuff? I’ve asked once if there is a chance for
Swift to support init(_ other: Self) { self = other } for classes. Joe Groff
replied this is called “factory initializer”.
This feature is highly needed for all the iOS developers out there who abuse
NIBs and create
I disagree it almost feels like a revert of SE–0110. If we had more than only:
parentheses
(angle) brackets
braces
A fifth set, that would also look visually fine with tuples. This discussion
would not even exist, no matter if the data structure behind the scenes is the
same or not. Parameter li
( /* two parameters, not a tuple */ (Int, Int) -> Void).self == (( /* one tuple
parameter */ (Int, Int)) -> Void).self // BUG, which SE-0110 should have fixed,
but still didn't
Plus inlined:
--
Adrian Zubarev
Sent with Airmail
Am 7. Juni 2017 um 13:53:08, Gwendal Roué (gwendal.r...@gmail.com)
-> Int synonymous again, either in some or in all contexts.
On Wed, Jun 7, 2017 at 05:41 Gwendal Roué via swift-evolution
wrote:
Le 7 juin 2017 à 12:33, Gwendal Roué a écrit :
Le 7 juin 2017 à 12:03, Adrian Zubarev via swift-evolution
a écrit :
Well please no:
let fn2: ((Int, Int))
Any update to this? I was hoping for a global announcement at WWDC to attract
more folks to join the discussions, but this didn’t happen.
--
Adrian Zubarev
Sent with Airmail
Am 10. Februar 2017 um 07:11:34, Bouke Haarsma via swift-evolution
(swift-evolution@swift.org) schrieb:
A big +1 for
Answer inlined:
Am 7. Juni 2017 um 12:33:51, Gwendal Roué (gwendal.r...@gmail.com) schrieb:
Le 7 juin 2017 à 12:03, Adrian Zubarev via swift-evolution
a écrit :
Well please no:
let fn2: ((Int, Int)) -> Void = { lhs, rhs in }
Instead use destructuring sugar pitched by Chris Lattner
Well I’m clearly against this, it doesn’t hurt to use some more paeans inside a
closure to tell the compiler if you want to destructure a tuple or use a single
argument for the whole tuple.
--
Adrian Zubarev
Sent with Airmail
Am 7. Juni 2017 um 12:31:47, Susan Cheng (susan.dog...@gmail.com)
Keep in mind there is also SE–0111 cometary which promises sugar for parameter
labels for closures:
// **
let foo(tuple:): ((Int, Int)) -> Void
// Sugar for **
let foo: (tuple: (Int, Int)) -> Void
What will happen if you’d always flatten here?
--
Adrian Zubarev
Sent with Airmail
Am 7. Juni
Well please no:
let fn2: ((Int, Int)) -> Void = { lhs, rhs in }
Instead use destructuring sugar pitched by Chris Lattner on the other thread:
let fn2: ((Int, Int)) -> Void = { ((lhs, rhs)) in }
That’s a correct error:
let fn3: (Int, Int) -> Void = { _ in }
This should be allowed, because we
Well /" "/ is far from being the queen of the beautiful syntaxes.
I summed up my thoughts in the following two gists:
https://gist.github.com/DevAndArtist/d9282e032ee241cfd1a403961cedffdf
https://gist.github.com/DevAndArtist/0c95f8549bb7d97387b360b4cfb3e09e
David Hart and I are patiently waiting
Would you prefer concatenation syntax using a trailing backslash over a
trailing double quote?
let s = "Long strings can be bro\
"ken into two or more pieces."
let s = "Long strings can be bro"
"ken into two or more pieces."
At least it seems reasonable and consist
Well the main complain I had during the discussion with David was, that I
previously had such a model in mind which will break up long double-quoted
string literals. Please look up this design in the alternative section of our
proposal. By adding slightly redundant multi-line string literal synt
I still have to disagree on that. Tuple patterns are not consistent in Swift.
Here is a small proof of my claim:
enum Foo {
case a(b: Int)
}
switch Foo.a(b: 10) {
case .a(b: let x):
print(x)
}
let tuple = (x: 2, y: 20)
switch tuple {
case (x: let a, y: let b):
pr
Exactly, everything else is simply an excuse and nothing more. Tuple
destructuring is not even aligned to enum case patterns at all, because it only
uses the shorthand version and does not allow us to write the full explicit
version.
enum Foo { case a(b: Int, c: Int) }
switch Foo.a(b: 42, c: 0
I had a short conversation on Twitter with Joe Groff, here is what he said
about it: “nowned/weak are meaningless inside a protocol”.
--
Adrian Zubarev
Sent with Airmail
Am 7. Mai 2017 um 13:54:28, Greg Spiers via swift-evolution
(swift-evolution@swift.org) schrieb:
Hello,
I hope this is t
1 - 100 of 765 matches
Mail list logo
