...@hartbit.com)) schrieb:
>
>
> > On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution
> > <swift-evolution@swift.org(mailto:swift-evolution@swift.org)> wrote:
> >
> > Hi there, I don’t mean to be rude or something, nor do I want to hold the
&
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
, no?
On Thu, Aug 17, 2017 at 04:47 Jonathan Hull via swift-evolution
<swift-evolution@swift.org> wrote:
+1
On Aug 17, 2017, at 2:38 AM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
This is a small pitch which I will abandon if there is not m
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
""" ==
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
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
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
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
;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
<swift-evolution@swift.org> wrote:
I wanted to read the proposal,
, 2017, at 12:42 PM, Tony Allevato via swift-evolution
<swift-evolution@swift.org> wrote:
On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong <del...@apple.com> wrote:
On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
Well the main
-evolution@swift.org> wrote:
On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong <del...@apple.com> wrote:
On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
Well the main debate is that, we all want early access to a f
Jun 28, 2017 at 11:15 AM Dave DeLong <del...@apple.com> wrote:
On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> 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
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
<swift-evolution@swift.org> wrote:
Hello folks,
Here is a quick and straig
+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
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:
but 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 Zub
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
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
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
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
Hello folks,
To keep things focused I opened up a new thread for this talk. Previously the
discussion took place at the thread named [Accepted] SE-0168: Multi-Line String
Literals.
John Holdsworth has provided a first draft in his PR:
https://github.com/apple/swift-evolution/pull/695
I think
y asking the community to consider it again.
On Wed, Apr 26, 2017 at 2:14 PM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
Hello folks,
To keep things focused I opened up a new thread for this talk. Previously the
discussion took place at the thread named [Accepted
“Out of scope for Swift 4” means that there is no time for it now and the
community should focus on features and issues yet to be solved in Swift 4. In
other words it means that you should defer the proposal at least until Swift 4
is released.
--
Adrian Zubarev
Sent with Airmail
Am 24.
This is somehow similar to
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-constants.
Question, will pattern matching still work fine with that? I kinda fear that
this won’t work in a different scopes, but feel free to prove me being wrong.
enum Foo {
case
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:
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
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
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
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
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:
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
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
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
e.
What exactly will `$0` refer to?
On Jun 24, 2017, at 7:10 PM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
Hello folks,
Here is a quick and straightforward pitch about @autoclosure. Currently the
attribute indicates that the caller has to pass an expression
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
+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
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
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
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
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
<swift-evolution@swift.org> a écrit :
Well please no:
let fn2: ((Int, Int)) -> Void = { lhs, rhs in }
Instead use destructur
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
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)
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
( /* 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é
(Int, Int) -> Int synonymous again, either in some or in all contexts.
On Wed, Jun 7, 2017 at 05:41 Gwendal Roué via swift-evolution
<swift-evolution@swift.org> wrote:
Le 7 juin 2017 à 12:33, Gwendal Roué <gwendal.r...@gmail.com> a écrit :
Le 7 juin 2017 à 12:03, Adrian Zubarev via
via swift-evolution
<swift-evolution@swift.org> 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
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
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
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
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
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
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
<swift-evolution@swift.org> wrote:
Hi Matthew,
Thank you for th
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
/032478.html.
On Jun 10, 2017, at 12:29 PM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> 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 hav
classes) would be eligible for storing by
`weak/unowned` reference.
On Jun 10, 2017, at 10:39 PM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> 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
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
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
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
<swift-evolution@swift.org> wrote:
The proposal is looking good to me. :) It wil
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:05 AM, Adrian Zubarev via swift
nstead.
On Jun 11, 2017, at 11:05 AM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
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
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
<swift-evolution@swift.org> wrote:
The proposal is looking good to me. :) It will also enabl
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):
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:
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
Hi there,
you’re a bit too late. A forum will come at some point (Discourse).
Best regards,
--
Adrian Zubarev
Sent with Airmail
Am 1. Mai 2017 um 13:30:55, Mohamed Ebrahim Afifi via swift-evolution
(swift-evolution@swift.org) schrieb:
Hi,
This is actually not a proposal to improve Swift,
erpart myTuple.somethingSpecial.
Am I still missing something out?
--
Adrian Zubarev
Sent with Airmail
Am 5. Mai 2017 um 07:43:49, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
Okay now I see where t
IMHO the following line of code contains a highly inconsistent syntax, because
the rhs uses labels for some sort of assignment, where the lhs just marks a
constant/variable after the colon.
let (x: x, y: y) = (x: 0, y: 0) // valid today
--
Adrian Zubarev
Sent with Airmail
Am 5. Mai 2017 um
Zubarev via swift-evolution
<swift-evolution@swift.org>:
I’m confused here. You’re referring to this example:
let pair = (x: 3, y: 5)
let swapped: (y: Int, x: Int) = pair
In this case you’re shuffling/swapping the labels of the type from:
(x: Int, y: Int) to (y: Int, x: Int), which f
I would assume the error is correct, because if we ban reordering than labeled
tuple types will become incompatible if the labels are swapped, remember the
strict order or labels.
--
Adrian Zubarev
Sent with Airmail
Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution
I’m confused here. You’re referring to this example:
let pair = (x: 3, y: 5)
let swapped: (y: Int, x: Int) = pair
In this case you’re shuffling/swapping the labels of the type from:
(x: Int, y: Int) to (y: Int, x: Int), which from my understanding of the whole
pitch should be an error. The
Labels create more harm in tuple destructuring than they solve.
let point = (x: 0, y: 0)
let (myX, myY) = point // fine
let (x: my_X, y: my_Y) = point // fine
let tuple = (a: 0, innerTuple: point)
let (myA, myInnerTuple) = tuple
// The following destructuring can extract nested tuples as well
I don’t understand your question. Those two lines of code should be an error
and it’s exactly what the current draft is trying to fix.
This behavior is truly inconsistent.
--
Adrian Zubarev
Sent with Airmail
Am 5. Mai 2017 um 14:07:11, André Videla (andre.vid...@gmail.com) schrieb:
If you
You’ve got your manual reordering wrong:
let a = (x: 1, y: 2)
var b: (y:Int, x:Int)
b = a // warning
b = (x: a.x, y: a.y) // explicit, manual reordering
It should be:
b = (y: a.y, x: a.x) // explicit, manual reordering
--
Adrian Zubarev
Sent with Airmail
Am 5. Mai 2017 um 11:48:50, Haravikk
that replaces indexed access like myTuple.1 to a
more readable counterpart myTuple.somethingSpecial.
Am I still missing something out?
--
Adrian Zubarev
Sent with Airmail
Am 5. Mai 2017 um 07:43:49, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift
Sorry I meant to say: “The point I was trying to make is that labels in tuples
have either a meaning or not at all."
--
Adrian Zubarev
Sent with Airmail
Am 5. Mai 2017 um 09:28:45, Adrian Zubarev (adrian.zuba...@devandartist.com)
schrieb:
The point I was trying to make is that labels in
Okay now I see where this is going. So basically you want to mirror the
behavior of function parameters into tuples.
You might want to be a little bit more explicit on types in your proposal to
better understand the so called ‘tuple shuffle’.
let a: (x: Int, y: Int) = (x: 1, y: 2)
var b: (y:
Personally I don’t see the latter as an issue, at least not in that particular
example of yours, because you can always look up the type of your labeled tuple.
Is there any benefit gained from labels in tuple destructuring? let (x: x, y:
y) is redundant to my eyes. If we ban reordering now,
Oh pardon, on the first glance I didn’t realized the issue with that example.
Here is an updated example that would work:
let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
This should work right? It’s assigning the inner tuple to second while also
creating two
I’m aware what a label is, I just had a small misunderstanding about nested
destructuring. ;-)
Issue solved for me.
let (a, b /* inner tuple */) = tuple
let (_, (x, y)) = tuple
+1 I don’t mind this change at all.
--
Adrian Zubarev
Sent with Airmail
Am 5. Mai 2017 um 08:14:10, Xiaodi Wu
Hi Robert,
I’m trying to understand the impact of your proposal and the feature you want
to remove from the language. Could you describe a little more on how if ever
this affects tuple destructuring?
var (a, b, c) = (0, "", 0)
(a, b) = (42, "Hello Swift")
(a = 42, b = "Hello Swift")
var (x,
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact
for sure. The point I was trying to make is that labels in tuples how either a
meaning or not at all.
// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)
// In this case the labels
Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
If we ban reordering now, than I don’t see choosing different names in tuple
destructuring as a strong argument of allowing labels there let (x: a, y: b).
They’re literally the same as one would write comments inside the
Besides the fact that those literals are an IDE gimmick supported only by Xcode
and Playgrounds (AppCode does not support them) and not compatible with
IBDesignable, I personally would recommend to use an UInt32 instead of a String.
#colorLiteral(rgba: 0xDB8B09FF)
--
Adrian Zubarev
Sent
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
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:
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 []
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
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)
-existentials/proposals/-enhanced-existentials.md.
Sent from my iPad
On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:
It’s part of Generalized Existentials, but does not make it complete. I think
it would be worth adding more an
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
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:
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
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
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
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,
ce'
} 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 on this :)
- Dennis
On Nov 25, 2017, at 12:13 AM, Adrian Zubarev via
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) ->
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:
601 - 700 of 719 matches
Mail list logo
