so there is no way to draw a parallel between integer literals and say ‘value’ ?
Could you provide an example? I don’t understand what you might mean.
--
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
http
I'd actually like to see a change in guard so that I don't need those
braces. I'd like something more readable like
| guard cond1 or return nil
| guard cond2 or throw MyError.IllegalValue
| guard cond3 or do { ... }
It may add more cases for the compiler to handle but in all cases I
used gu
I apologize for the tons of typos I make. :/
--
Adrian Zubarev
Sent with Airmail
Am 31. Mai 2016 um 21:55:53, Adrian Zubarev (adrian.zuba...@devandartist.com)
schrieb:
I'd actually like to see a change in guard so that I don't need those
braces. I'd like something more readable like
| gua
I added the example I posted in my last reply and submitted a pull request.
--
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
So basically if my application terminates without errors or crashes I can be
sure that the OS will free any memory it used.
Now I feel safe using UnsafeMutablePointers in swift :)
--
Adrian Zubarev
Sent with Airmail
Am 1. Juni 2016 um 18:19:01, Austin Zheng (austinzh...@gmail.com) schrieb:
the proposal.
>
> I.e. IMO current `return` in properties and functions is less evil than
> absent of `return` in `guard`.
>
>> On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:
>> Here is the draft proposal:
>> https://github.com/DevAndArtist/
1.06.2016 20:03, Adrian Zubarev via swift-evolution wrote:
> Given that Swift 3 is winding down, we are in a mode of declining PRs
> for proposals that don’t align with its goals. Please bring this back
> up for discussion this fall, thanks for understanding.
>
> Closed by Chr
I like the decision of the core team to replace protocol<…> with something like
& instead. This gives us room to rethink Any<…> or come up with even better
mechanism for existentials. :)
There are still a few things to consider:
AnyObject and AnyClass:
I’d prefer to drop the current AnyClass an
I added a draft proposal here:
https://github.com/DevAndArtist/swift-evolution/blob/rename_anyobject_remove_anyclass/proposals/-rename-anyobject-remove-anyclass.md
Rename AnyObject and remove current AnyClass
Proposal: SE-
Author(s): Adrian Zubarev
Status: Awaiting review
Review manager:
.
So I am happy staying with AnyObject, as it describes what the actual instance
is. And if AnyValue comes, they would pair nicely together.
Patrick
On 9 Jun 2016, at 8:08 PM, Adrian Zubarev via swift-evolution
wrote:
I added a draft proposal here:
https://github.com/DevAndArtist/swift
On 9 Jun 2016, at 9:23 PM, Adrian Zubarev via swift-evolution
wrote:
So what is the counterpart to AnyClass aka. AnyObject.Type for AnyValue? There
is no and I don’t see any good name for it.
You could just use AnyValue.Type?
So basically you’re for consistency for `AnyValue` but not for
There could be one day more than one reference type, and AnyObject could also
work with that.
Classes are not the only reference types. Closures are reference types which we
CANNOT extend with protocols.
--
Adrian Zubarev
Sent with Airmail
___
swift
I just installed the current Swift 3 snapshot to play around with it (last from
may crashed my Xcode all the time).
I wanted to re-build a small project with (currently implemented) Swift 3
changes. Basically I had to look up on GitHub what the default value for
deinitialize(count:) function wa
Yes please, current Swift 3 Snapshot translated a lot of C functions from not
optionals to optionals just because let and var works correctly on
UnsafeMutablePointer’s.
This is confusing and ugly:
public func freeaddrinfo(_: UnsafeMutablePointer!)
public func gai_strerror(_: Int32) -> UnsafePoi
Is this some wrong api translation or something?
extension String {
/// The index type for subscripting a string.
public typealias Index = String.CharacterView.Index
/// A type used to represent the number of steps between two `String.Index`
/// values, where one value is reachab
Just looked up the current implementation of this:
extension String {
/// The index type for subscripting a string.
public typealias Index = CharacterView.Index
/// A type used to represent the number of steps between two `String.Index`
/// values, where one value is reachable from the ot
What is the status for this idea? I can’t find the proposal for this. :(
--
Adrian Zubarev
Sent with Airmail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
If there is no proposal yet, I could write one. We should sketch out what we
should consider for nested protocols. I’d love to see this feature in Swift 3.
:)
Should this be allowed? I’m not sure what and what not we’ll see of generics in
Swift 3.
// A.P1
class A {
protocol P1: clas
:char...@charliemonroe.net)) schrieb:
>
>
> > On Jun 11, 2016, at 3:35 PM, Adrian Zubarev via swift-evolution
> > mailto:swift-evolution@swift.org)> wrote:
> >
> > I just installed the current Swift 3 snapshot to play around with it (last
>
=D
We’re already discussing this in a lot (I mean really lot) different
threads.
Search for existentials or Any<…> or type<…> or All<…>.
SE–0095 is the first step in that direction. We want a shorthand version first
and design a more complex functionality like Any<…> later.
Any (I prefer
Not true, we already stated a clear rule how existentials should work with
class-requirements long time ago (don’t mind lowercased any here):
Nested any<...>
A nested any<...> may declare a class or any-class constraint, even if its
parent any<...> contains a class or any-class constraint, or a
One more thing for clarity:
Any-class requirement: This must be the first requirement, if present. This
requirement consists of the keyword class, and requires the existential to be
of any class type.
Class requirement: This must be the first requirement, if present. This
requirement consists
//gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051
Regards
(From mobile)
On Jun 14, 2016, at 11:44 PM, Adrian Zubarev via swift-evolution
wrote:
One more thing for clarity:
Any-class requirement: This must be the first requirement, if present. This
requirement consists of the ke
> >
> >
> > On Jun 15, 2016, at 8:24 AM, Adrian Zubarev via swift-evolution
> > mailto:swift-evolution@swift.org)> wrote:
> >
> > >
> > > I guess you don’t understand that a so called proposal should have enough
> > > detail
Shouldn’t it act theoretically something like this:
// Begin file A (which acts like a scope)
// where `type` can be enum, struct, class or protocol
private type X {}
fileprivate type Y {}
public struct Z {
var x: X
var y: Y
}
// End file A
private should always behave the same
How about this, it might make more sense and relax the behavior a little:
// 1. file scope (Level 0)
// Level 0 because its declared at file scope
private struct A {
/* implicit private */ init() {} // Level 1
}
// Level 0
struct B {
// `A` is visible here and is seen as `fil
Ok I already see side effects in my idea which breaks the entire scoped access
level thing :/
class A {
// incrementTwice() is not visible here
}
extension A {
private func incrementTwice() {
}
}
In my model incrementTwice would be visible in A which it shouldn’t (I agree to
that).
T
Shouldn’t a file act like an individual scope? If so why would A be visible in
C? Is it because files act not a lexical scopes?
--
Adrian Zubarev
Sent with Airmail
Am 15. Juni 2016 um 21:34:23, Adrian Zubarev (adrian.zuba...@devandartist.com)
schrieb:
Your example #2 is just incorrect. `A`
I was referencing to the issue Robert discovered in his implementation.
I do understand what the proposal is all about, but thank you for re-clarifying
that to me. :)
--
Adrian Zubarev
Sent with Airmail
Am 15. Juni 2016 um 21:40:37, Matthew Johnson (matt...@anandabits.com) schrieb:
What see
Its my bad habit describing everything as a ‘bug’. Don’t judge me for that. I
fully agree with you about the whole issue.
You probably missed // 2. file scope (Level 0), but it’s okay. So my second
example was indeed correct. I described ‘levels’ starting from zero for each
individual file, bec
+1 very much for consistency.
--
Adrian Zubarev
Sent with Airmail
Am 16. Juni 2016 um 21:51:48, Patrick Pijnappel via swift-evolution
(swift-evolution@swift.org) schrieb:
Due to considerably support on this thread, a draft proposal to revisit the
core functional method exceptions to the -ed
I’ve spotted some inconsistency on access control modifier I’d like to discuss
in this thread (the behavior is not groundbreaking but inconsistent from
readers and developers view perspective).
Why are extensions not marked as public in public apis when the module is
imported?
Any type members
One problem I found with the mentioned suggestion of mine is this:
public protocol A {}
public class B {}
// 'public' modifier cannot be used with
// extensions that declare protocol conformances
public extension B: A {}
Why is that like this?
Can this be fixed?
Implicit public extension feels
@implicitreturn guard a = b else { print(“foo”) }
Isn’t that just the same? I mean now you even write more boilerplate then
bebore.
How does your return type look, what are you trying to solve?
--
Adrian Zubarev
Sent with Airmail
Am 20. Juni 2016 um 08:30:39, Yarden Eitan via swift-evolution
Everyone does feel comfortable with implicit public extensions?
--
Adrian Zubarev
Sent with Airmail
Am 19. Juni 2016 um 09:18:35, Adrian Zubarev (adrian.zuba...@devandartist.com)
schrieb:
One problem I found with the mentioned suggestion of mine is this:
public protocol A {}
public class B
Access control modifier: public > internal == /* implicitly internal */ >
fileprivate >= private
//= TOPLEVEL / File - Scope
//= some protocols
public protocol A {
func aa()
}
private protocol B {
func bb()
}
fileprivate protocol C {
func cc()
}
Just yesterday I filed a bug because Data and DispatchData overlap but the api
is not consistent: https://bugs.swift.org/browse/SR–1843
I never used libdispatch in depth but wanted to learn how it works to evolve my
TCP module.
At first glance I spotted one wrong label name on DispatchIO:
publ
Should there be a design guideline rule for colons : in Swift?
I see people doing things like this:
protocol A : B {}
// VS.
protocol A: B {}
func foo() -> T { … }
// VS.
func foo() -> T { … }
var value : Type
// VS.
var value: Type
[key1 : value1, key2 : value2]
// VS.
[key1: value1, key
22.06.2016 14:40, Adrian Zubarev via swift-evolution wrote:
> Should there be a design guideline rule for colons |:| in Swift?
>
> I see people doing things like this:
>
> |protocol A : B {} // VS. protocol A: B {} |
>
> |func foo() -> T { … } // VS. func foo
The whole guideline won’t stop people from writing crappy code, you’re not even
forced to read it. :D
--
Adrian Zubarev
Sent with Airmail
Am 22. Juni 2016 um 15:36:47, Brandon Knope (bkn...@me.com) schrieb:
This is one of those things that *could* have a guideline, but it still
wouldn't sto
I’d love to see something like this happen to Xcode. I’m curious if we could
write an extension for Xcode 8 to refactor code to at least some of the
conventions.
--
Adrian Zubarev
Sent with Airmail
Am 22. Juni 2016 um 15:43:44, Charlie Monroe (char...@charliemonroe.net)
schrieb:
It would,
Airmail
Am 22. Juni 2016 um 17:21:49, Charlie Monroe (char...@charliemonroe.net)
schrieb:
On Jun 22, 2016, at 5:07 PM, Erica Sadun via swift-evolution
wrote:
On Jun 22, 2016, at 8:36 AM, Adrian Zubarev via swift-evolution
wrote:
I’d love to see something like this happen to Xcode. I’m
This also depends on the keyboard layout you have. I mean looking at the
English keyboard layout the \ character is presented and easily accessible with
just a single tap.
For me it’s always been a problem, this is not a strong argument for changing
that behavior but it would ease at least my w
You might consider the topic I started about access modifier on extensions. LINK
Fixing this would be a breaking change, because:
if you never explicitly set public modifier the visibility would break
fixing implicit public modifier on extensions would mean fixing the problems
with protocols + e
Not with this proposal, but this should be allowed at a later point.
This would work as a workaround.
protocol A { }
protocol B { }
typealias AB = A & B
struct Foo : AB { }
class SuperClass { }
class SubClass : SuperClass, AB { }
It’s up to the core team to decide if your mentioned behavior sh
I don’t like an underscore on public protocols. If we’re not forced to use the
proposed syntax at all it looks strange when you use a type with an underscore
(which to me represents something for private or internal usage).
In Swift we only can use literals for a single direction literal -> type
I’m aware of that fact, but all types with underscore even in the stdlib
telling me to keep my hands of them, because something might happen to them.
As an example we have _Strideable protocol which is visible by its name, but
its declaration isn’t visible at all:
// FIXME(ABI)(compiler limitat
library team. The intent
is for the use of underscore here to be consistent with other uses of
underscore prefix in the standard library. I’m not sure why you think this is
different than the rest...
On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution
wrote:
I’m aware of that
comes from the standard library team. The intent
is for the use of underscore here to be consistent with other uses of
underscore prefix in the standard library. I’m not sure why you think this is
different than the rest...
On Jun 24, 2016, at 10:22 AM, Adrian Zubarev via swift-evolution
Originally I started this topic in a discussion thread but moved it now into
its own proposal thread due the lack of feedback.
This proposal contains a breaking change!
You can read a formatted version here:
https://gist.github.com/DevAndArtist/8f1113b6d5d0379ebf82bd227cf4a88d
Feel free to als
We’re running out of time, and there is still no feedback although Chris
Lattner said to consider this topic in his thread: Partial list of open Swift 3
design topics
I’m not sure if we’re allowed to PR even if there is no feedback at all.
Again this is a breaking change!
--
Adrian Zubarev
Se
Proposal is moved to a git repo:
https://github.com/DevAndArtist/swift-evolution/blob/extensions_access_modifiers/proposals/-extensions-access-modifiers.md
I also updated a few things for readability.
Revising access modifiers on extensions
Proposal: SE-
Author: Adrian Zubarev
Status: Aw
Hi, Adrian. Can you explain why you want to make this change? “public” on an
extension doesn’t mean anything by itself because you can’t refer to an
extension as an entity in and of itself. Access modifiers are disallowed on
extensions with protocols because the conformance isn’t controlled by t
I did a mistake in my last reply which I’m correcting here. I meant structs
instead of protocols B and C:
internal protocol A { func foo() }
public struct B : A {
// foo won't be visible when imported
func foo() {}
}
public struct C : A {
// we can grant foo more visib
And yet another correction of the default protocol implementations part of my
reply.
The imported module is correct, but the default implementation is not imported
(I relied on Xcode which didn’t raise an error before I started building the
project where I was using the module, and I didn’t bui
I completely rewritten the proposal, you can read the formatted version here:
https://github.com/DevAndArtist/swift-evolution/blob/19f2583209a5763880e6f6fa6738ea0c6011f2d6/proposals/-extensions-access-modifiers.md
--
Adrian Zubarev
Sent with Airmail
Am 27. Juni 2016 um 12:58:53, Adrian Zu
Correcting myself over and over. Here is the correct url:
https://github.com/DevAndArtist/swift-evolution/blob/extensions_access_modifiers/proposals/-extensions-access-modifiers.md
--
Adrian Zubarev
Sent with Airmail
Am 27. Juni 2016 um 14:39:41, Adrian Zubarev (adrian.zuba...@devandartis
I still have no idea why you want to make this change, other than “putting an
access modifier on an extension is different from putting an access modifier on
a type”. Are you trying to hide protocol conformances that would be otherwise
public?
In my proposal I cannot hide a public protocol confo
“The access modifier of an extension sets the default modifier of its members
which has no modifier applied to them.”
public extension SomeType {
func extensionMember() {}
}
“If there the extension has no access modifier, then the default modifier of
its members which has no explicit modifier
If you want consistent behavior, the proposal should just be “remove access
modifiers from extensions”. That way, access for members follows the same
defaults as in the original type. The only purpose for access modifiers on
extensions is to change the default, so if you don’t like the behavior
I apologize for all the typos I make, I’m way too tired and it’s already late
night for me. (I just feel like I need to apologize :] )
I meant:
Anything else I may need to change to drive my proposal into that direction?
--
Adrian Zubarev
Sent with Airmail
Am 28. Juni 2016 um 00:17:35, Adri
How do private or fileprivate help extensions in general? Is really laziness a
strong argument over consistency and clarity?
As for your example I’d have a pretty good solution (I can’t say this will be
accepted, but the idea is great, at least I think that way. I’d propose for
that feature aft
Laziness of typing out fileprivate on all extension members.
group is exactly what access modifier do right now on extensions.
Current access control on extensions is a mix of the access control from
classes (enums and struct) and the access control from protocols (which is like
groups will wor
How about:
public enum Syntax {
public enum Literal {
public typealias NilProtocol = ...
public typealias BooleanProtocol = ...
public typealias IntegerProtocol = ...
public typealias FloatProtocol = ...
public typealias UnicodeScalarProtocol = ..
In fact this doesn’t tell you that you can do this:
func f() -> T {
return T(integerLiteral: 43) // Error
return T(43) // Also an Error
}
As I already said, literals will be read and converted to an actual type, but
to adopt this, your time needs conformance to a protocol (sounds trivial
That silly autocorrection sometimes:
As I already said, literals will be read and converted to an actual type, but
to adopt this, your type needs conformance to a protocol (sounds trivial?).
--
Adrian Zubarev
Sent with Airmail
Am 29. Juni 2016 um 08:44:58, Adrian Zubarev (adrian.zuba...@deva
And just as a side note: the example does work like this:
func f() -> T {
return T(integerLiteral: 43 as! T.IntegerLiteralType) // Error
}
func g() -> T {
return T(integerLiteral: 43)
}
let test: Int = f()
let test2: Int = g()
I assume everyone does know that. The example by itself
Wow so much sarcasm in this thread! *thumbs up*
--
Adrian Zubarev
Sent with Airmail
Am 29. Juni 2016 um 08:55:18, Dave Abrahams via swift-evolution
(swift-evolution@swift.org) schrieb:
> Arg. Dang it!
>
> Syntax.ExpressibleAsIntegerLiteral
+1
IMO it's not possible to improve on that one.
_
Dear Swift community, as most of you may know we’ve been discussing the future
of extintials and diverse design ideas. The result for Swift 3 is a proposal
which makes the first step by replacing procotol with a new shorthand
syntax A & B.
The reason I’m posting this proposal so early is to get
hings like
`SequenceType` which had the semantic that conforming types *are* sequences).
-Matthew
Thank you for bringing this into the conversation!
-- E
On Jun 29, 2016, at 12:31 AM, Adrian Zubarev via swift-evolution
wrote:
How about:
public enum Syntax {
public enum Li
s not* used in the sense that it used to be used in things like
`SequenceType` which had the semantic that conforming types *are* sequences).
-Matthew
Thank you for bringing this into the conversation!
-- E
On Jun 29, 2016, at 12:31 AM, Adrian Zubarev via swift-evolution
wrote:
How
Zubarev
Sent with Airmail
Am 29. Juni 2016 um 16:55:10, Matthew Johnson (matt...@anandabits.com) schrieb:
On Jun 29, 2016, at 9:46 AM, Adrian Zubarev via swift-evolution
wrote:
I wouldn’t use the Type suffix, because I believe this will create even more
confusion with the associatedtype
found here:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html
It uses a bit different syntax, but the gist of it seems the same to me...
On Jun 29, 2016, at 3:49 PM, Adrian Zubarev via swift-evolution
wrote:
Dear Swift community, as most of you may know we’ve
Feel free to move the further discussion into my thread with an enhanced
mechanism called group. Thread link.
--
Adrian Zubarev
Sent with Airmail
Am 19. Juni 2016 um 20:24:31, Raphaël Wach via swift-evolution
(swift-evolution@swift.org) schrieb:
Also, even if the sample code with the 3 exte
I would like to discuss about the following topic.
Wouldn't it be better to enforce argument labels on tuples types, if the tuple
type defines them?
```swift
func foo(tuple: (a: Int, b: Int)) { /* do something */ }
let test1 = (10, 100)
let test2: (a: Int, c: Int) = test
let test3: (Int, Int)
that can't be fixed using policy
> (thou shalt label tuple arguments) at your organization, or structs?
>
> Cheers,
> - Will
>
>
> > On Apr 20, 2016, at 6:23 AM, Adrian Zubarev via swift-evolution
> > mailto:swift-evolution@swift.org)> wrote:
> &
That’s why I’d like to discuss this topic and hear all your feedback.
Do you think it might be possible to add some optional extra flag to the
language to enforce argument labeling. Not only for tuples as I started the
discussion with but also for argument labels on blocks/closures?
```swift
@
I forgot something in my previous post:
```swift
@require_argument_label
func foo(block: (boo: Int) -> Void) { /* pass boo to block */ }
foo() { boo in // do is enforced here
/* do some work*/
}
```
--
Adrian Zubarev
Am 20. April 2016 bei 19:59:23, Adrian Zubarev
(adrian.zuba...@de
@Austin I wasn’t talking about the tuple splat feature here.
In my case I was trying to simplify the example of a function that awaits an
actual tuple of a specific type, which in my case also (should) have argument
labels.
```swift
func foo(tuple: (a: Int, b: Int)) {}
let tuple = (10, 42)
fo
Personally I'm fine with the way it is right now, but I do miss enforced labels
at some point. At least it would be 'nice to have' feature like we already have
@autoclosure or @noescape to enforce some specific behaviour.
I started the discussion about enforcing argument labels on tuples but wit
I know that :D I mean < and > are considered as normal characters of the string
"<\(quote)> by <\(person)>“ so thats why this won’t work that way.
--
Adrian Zubarev
Am 21. April 2016 bei 11:32:05, Daniel Höpfl via swift-evolution
(swift-evolution@swift.org) schrieb:
Maybe using "<\(quote)> by
I’d like to throw an idea in the room and see where this will go.
What if Swift would allow us to create custom infix functions?
Does Swift need to ability of infix functions?
How powerful can such a feature be?
Pros and cons?
There is a discussion about the `with` statement which we could devel
I must correct myself, I’m a bit sleepy.
infix func with(lhs: T, rhs: @noescape (T) -> Void) -> T {
rhs(lhs)
return lhs
}
This one will do the trick.
--
Adrian Zubarev
Am 22. April 2016 bei 21:07:00, Adrian Zubarev
(adrian.zuba...@devandartist.com) schrieb:
I’d like to throw an idea
i 22:05:11, Vladimir.S via swift-evolution
(swift-evolution@swift.org) schrieb:
On 22.04.2016 22:06, Adrian Zubarev via swift-evolution wrote:
> I’d like to throw an idea in the room and see where this will go.
>
> What if Swift would allow us to create custom infix functions?
> Does
ith` statement is just a single example we could create with infix functions.
--
Adrian Zubarev
Am 22. April 2016 bei 22:05:11, Vladimir.S via swift-evolution
(swift-evolution@swift.org) schrieb:
On 22.04.2016 22:06, Adrian Zubarev via swift-evolution wrote:
> I’d like to throw an idea in t
Hello Swift community, I’d like to throw a few more ideas on what features
future Swift version might or should have.
I’d like to talk about implicit protocols for reference and value types first
and then about type oriented protocols.
As everyone know Swift has a great differentiation between r
I already see the problem here:
class A { var x: Int { return 42 } }
class B: A { override let x = 7 } // assume that will work
class C: B { override var x: Int { /* wait this wont work anymore */ } }
You won’t be able to override an immutable constant.
I don’t like such a change.
--
Adrian Zu
+1 But your example is too good to be true. :)
What would happen to this code:
class A {
var value: Type? = nil
func reset() { self.value = nil }
func test() {
self.value = self.value ?? Type()
self.reset()
self.value.doSomething()
// can the compiler be sure that
+1 Yes please, get rid of the `class` keyword from protocols already and
replace it with better implicit protocols.
I posted the idea two weeks ago, but no one answered to it:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015568.html
Replacing `class` with somethin
| :
: +++ +-+-+ :
--
Adrian Zubarev
Sent with Airmail
Am 3. Mai 2016 bei 18:42:15, Adrian Zubarev via swift-evolution
(swift-evolution@swift.org) schrieb:
+1 Yes please, get rid of the `class` keyword from protocols already and
replace it with better
> +--+---+ +-++
> > > | AnyReference | | AnyValue |
> > > +--+---+ +-++
> > > | |
> > > ++-+ ....
> > > | AnyObject (ObjC) | : Optionally Swift could also
I kinda feel my idea went into the wrong direction.
By introducing these implicit protocols (formatted with Source Code Pro font) I
didn’t meant them to force a type to have only reference or value semantics.
+---+
| Any |
+---+---+
This one have bothered me for days, since the idea came to my mind.
I don't want to be too futuristic so here are my first thoughts.
What if Swift 3 would have the ability to merge types and protocols together?
Sure we will see generic typealias in Swift 3 but it doesn't allow us merge
value ty
-1 as well. Everything has already been said by the community. Swift should
evolve on its own and don't care around old garbage. true and false is and was
the best way to express a boolean.
--
Adrian Zubarev
Am 5. Mai 2016 um 11:56:55, Jacopo Andrea Giola via swift-evolution
(swift-evoluti
Definitely a welcome change from me (+1). But this proposal makes me curious
about the impact on the `AnyObject` protocol?
let string = "foo"
let nsString = string as AnyObject
nsString.dynamicType // _NSCFConstantString.Type
NSString().dynamicType // __NSCFConstantString.Type // there are two di
Wouldn’t this enforce enum cases and some static struct variables to be
lowercase?
public enum UINavigationControllerOperation: Int {
case None
case Push
case Pop
}
public struct NSLayoutFormatOptions: OptionSetType {
public init(rawValue: UInt)
public static var Al
+1 I can’t wait for Swift 3 anymore. This ability would be great.
Additionally what do you think about something like this?
protocol DelegatableType {
protocol Delegate: class // enforced you to create a nested protocol
weak var delegate: Delegate? // or Self.Delegate?
}
class A: De
Great I missed that change. Im fine with that change. :) I'd be happy to see
`.self` being removed as well.
--
Adrian Zubarev
Am 6. Mai 2016 um 09:25:01, Pyry Jahkola
(pyry.jahk...@iki.fi(mailto:pyry.jahk...@iki.fi)) schrieb:
>
>
> > On 06 May 2016, at 10:19, Adrian
For me and my English its become hard to follow where this is going right now.
Let’s stick with my `AnyReference` and `AnyValue` protocols just for the
example.
Do I get your intention right that we discuss here about value types that are
constructed from their deepest only from other value typ
again? I checked SR-0006 and it still has protocols like
`Any`, `AnyIterator` or `AnyCollectionProtocol`.
--
Adrian Zubarev
Am 9. Mai 2016 um 21:38:22, Joe Groff
(jgr...@apple.com(mailto:jgr...@apple.com)) schrieb:
>
>
> > On May 6, 2016, at 12:04 AM, Adrian Zubarev vi
201 - 300 of 765 matches
Mail list logo
