Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

2016-06-09 Thread Adrian Zubarev via swift-evolution
On 9 Jun 2016, at 9:23 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> 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 consi

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

2016-06-09 Thread Adrian Zubarev via swift-evolution
having both AnyStruct and AnyEnum. 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 <swift-evolution@swift.org> wrote: I adde

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

2016-06-09 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

2016-06-09 Thread Adrian Zubarev via swift-evolution
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 ___

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

2016-06-12 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Returned for Revision] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

2016-06-04 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-28 Thread Adrian Zubarev via swift-evolution
gt; > On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution > > <swift-evolution@swift.org> wrote: > > > > > The idea is simple: > > > > > > • Can we make return keyword optional in cases like this? > > > • Shouldn’t this behav

[swift-evolution] [Pitch] Make `default` function parameter values more transparent

2016-06-11 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Pitch] Make `default` function parameter values more transparent

2016-06-13 Thread Adrian Zubarev via swift-evolution
...@charliemonroe.net)) schrieb: > > > > On Jun 11, 2016, at 3:35 PM, Adrian Zubarev via swift-evolution > > <swift-evolution@swift.org(mailto:swift-evolution@swift.org)> wrote: > > > > I just installed the current Swift 3 snapshot to play around with it (las

[swift-evolution] [Discussion] Type hierarchy translation consistency

2016-06-11 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

2016-06-11 Thread Adrian Zubarev via swift-evolution
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) ->

Re: [swift-evolution] [Discussion] Type hierarchy translation consistency

2016-06-12 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] Property with class and protocol type

2016-06-14 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] Property with class and protocol type

2016-06-15 Thread Adrian Zubarev via swift-evolution
none. https://gist.github.com/lmihalkovic/68c321ea7ffe27e553e37b794309b051 Regards (From mobile) On Jun 14, 2016, at 11:44 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: One more thing for clarity: Any-class requirement: This must be the first requirement, if

Re: [swift-evolution] Property with class and protocol type

2016-06-15 Thread Adrian Zubarev via swift-evolution
t-evolution@swift.org)> wrote: > > > > > > On Jun 15, 2016, at 8:24 AM, Adrian Zubarev via swift-evolution > > <swift-evolution@swift.org(mailto:swift-evolution@swift.org)> wrote: > > > > > > > > I guess you don’t understand that

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-31 Thread Adrian Zubarev via swift-evolution
, Brian Christensen via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>>> The idea is simple: >

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-31 Thread Adrian Zubarev via swift-evolution
I feel like return is very important part of guard statement. I understand the requirement for consistency with properties/closures/functions, but I’ll prefer to have some inconsistency in language in this case and require return for guard. And in case I’ll have to choose all-or-nothig, I’ll

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-31 Thread Adrian Zubarev via swift-evolution
I really like the proposal in case of properties and functions, but I  really don't want to have  guard boolean else { "false" }  I feel like `return` is very important part of `guard` statement.  I understand the requirement for consistency with  properties/closures/functions, but I'll prefer to

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-31 Thread Adrian Zubarev via swift-evolution
Exactly.  You are allowed to omit `return` if the entire body only consists of `return some().expression` Thats where the useless example comes in (but we don’t need this behavior at all): func foo(boolean: Bool) {     guard boolean else {}     print("true“) } I made some changes to the

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-31 Thread Adrian Zubarev via swift-evolution
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  |

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-31 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] Enhanced existential types proposal discussion

2016-05-26 Thread Adrian Zubarev via swift-evolution
I’d like to throw one idea of mine in the room I couldn’t stop thinking when I read one of Thorsten’s replies on SE–0095 review thread. This wiki section explains the existential types where we have something like this: "T = ∃X { a: X; f: (X → int); } This could be implemented in different

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

2016-05-26 Thread Adrian Zubarev via swift-evolution
I’m not against Any<…> or something, I just wanted to throw this in the room because I’ve seen someone being confused about what Any<…> might mean. The generic manifesto has a nice wordplay that explains the true meaning: “Any type that conforms to … (all constraints) … .” But someone might

Re: [swift-evolution] [swift-users] Unsafe(Mutable)Pointer (suc)predecessor and advancedBy functions

2016-05-26 Thread Adrian Zubarev via swift-evolution
This is where it gets tricky. When you create a chunk of memory using 'UnsafeMutablePointer.memory()' or 'alloc()', it's as if you are programming in C with 'malloc' and 'free'. The memory you create and the objects you put in that memory don't participate in ARC - the runtime will not track

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0095: Replace protocol<P1, P2> syntax with Any<P1, P2>

2016-05-27 Thread Adrian Zubarev via swift-evolution
Moving this review to where it belongs. Not sure who renamed it to SE–0089?! --  Adrian Zubarev Sent with Airmail Am 27. Mai 2016 bei 16:58:16, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb: On May 27, 2016, at 3:57 AM, Thorsten Seitz wrote:

[swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-27 Thread Adrian Zubarev via swift-evolution
The idea is simple: Can we make return keyword optional in cases like this? Shouldn’t this behave like @autoclosure or @noescape? type A { var characters: [Character] = … var string: String { String(self.characters) } var count: Int { 42 } } Is this worth a proposal or Swifty enough,

Re: [swift-evolution] Enhanced existential types proposal discussion

2016-05-26 Thread Adrian Zubarev via swift-evolution
I alway enjoy hearing your ideas. This is quite interesting. It's basically a way to define an ad-hoc interface that a type doesn't need to explicitly declare it conforms to. I know Golang works similarly; if a Go type implements all the requirements of an interface it conforms automatically.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

2016-05-26 Thread Adrian Zubarev via swift-evolution
There is great feedback going on here. I'd like to consider a few things here: What if we name the whole thing `Existential<>` to sort out all confusion? This would allow `typealias Any = Existential<>`. Should `protocol A: Any` replace `protocol A: class`? Or at least deprecate it. Do we

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-06-01 Thread Adrian Zubarev via swift-evolution
l give -1 for 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/

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-06-01 Thread Adrian Zubarev via swift-evolution
, 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 Chris. Sad but we’

Re: [swift-evolution] [swift-users] UnsafeMutablePointer vs. UnsafeMutablePointer

2016-06-01 Thread Adrian Zubarev via 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:

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-31 Thread Adrian Zubarev via swift-evolution
+1. This is example *is not* a single expression code block. There are 3 expressions (the condition, the return value in the else block, and the primary return value).  The `else` block is a returning single expression block. I can’t show the `guard` example without any returning scope. You

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

2016-05-31 Thread Adrian Zubarev via swift-evolution
Please remove the section on guard as any of the preceding will never have single expression top level code blocks if they contain a guard clause. I didn’t get this at first but now I see your point, it’s because the whole returning scope will need `return` at the very end so `guard` should

Re: [swift-evolution] Enhanced existential types proposal discussion

2016-05-29 Thread Adrian Zubarev via swift-evolution
t Collection constraint Collection.Element == T } --  Adrian Zubarev Sent with Airmail Am 26. Mai 2016 bei 22:56:10, Matthew Johnson (matt...@anandabits.com) schrieb: On May 26, 2016, at 3:39 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: I alway enjoy hearing your ide

Re: [swift-evolution] Swift 3 vs "additive" proposals

2016-06-22 Thread Adrian Zubarev via swift-evolution
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 +

Re: [swift-evolution] [Discussion] Design guideline rule for `:`

2016-06-22 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Discussion] Design guideline rule for `:`

2016-06-22 Thread Adrian Zubarev via swift-evolution
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,

Re: [swift-evolution] [Discussion] Design guideline rule for `:`

2016-06-22 Thread Adrian Zubarev via swift-evolution
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() -> T

[swift-evolution] [Discussion] Design guideline rule for `:`

2016-06-22 Thread Adrian Zubarev via swift-evolution
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,

Re: [swift-evolution] [Review] SE-0095: Replace `protocol<P1, P2>` syntax with `Any<P1, P2>`

2016-06-22 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

2016-06-15 Thread Adrian Zubarev via swift-evolution
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.  

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

2016-06-15 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

2016-06-15 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

2016-06-15 Thread Adrian Zubarev via swift-evolution
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).

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

2016-06-15 Thread Adrian Zubarev via swift-evolution
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,

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

2016-06-15 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] Property with class and protocol type

2016-06-14 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

2016-06-16 Thread Adrian Zubarev via swift-evolution
+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

[swift-evolution] [Discussion] access control modifier inconsistency

2016-06-17 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [SE-0088] Dispatch API names

2016-06-21 Thread Adrian Zubarev via swift-evolution
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:

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

2016-06-24 Thread Adrian Zubarev via swift-evolution
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 ->

Re: [swift-evolution] Fw: Re: [Proposal Draft] Literal Syntax Protocols

2016-06-24 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] Fw: Re: [Proposal Draft] Literal Syntax Protocols

2016-06-24 Thread Adrian Zubarev via swift-evolution
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 <swift-evolution@swift.

[swift-evolution] Fw: Re: [Proposal Draft] Literal Syntax Protocols

2016-06-24 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

2016-06-27 Thread Adrian Zubarev via swift-evolution
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,

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

2016-06-26 Thread Adrian Zubarev via swift-evolution
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:

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

2016-06-26 Thread Adrian Zubarev via swift-evolution
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

[swift-evolution] [Proposal] Revising access modifiers on extensions

2016-06-25 Thread 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

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

2016-06-27 Thread Adrian Zubarev via swift-evolution
“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

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

2016-06-27 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

2016-06-29 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

2016-06-29 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

2016-06-29 Thread Adrian Zubarev via swift-evolution
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.

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

2016-06-29 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [proposal] Generic type aliases

2016-03-21 Thread Adrian Zubarev via swift-evolution
Ok I read all the previous posts and I’m totally fine with this feature as it’s mentioned in its base form. Looking forward to see generic typealias allowing type constraints. There is one thing still on my mind: how do we use a generic typealias? typealias SomeTuple = (T, T) func foo(tuple:

Re: [swift-evolution] [Idea] custom infix functions

2016-04-22 Thread Adrian Zubarev via swift-evolution
le 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 the room and see where this will go. > >

[swift-evolution] [Idea] implicit protocols and type oriented protocols

2016-04-23 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] Overriding computed properties with let constants?

2016-04-23 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] Auto Unwrapping Of Optionals

2016-04-29 Thread Adrian Zubarev via swift-evolution
+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

[swift-evolution] [Idea] custom infix functions

2016-04-22 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] [Idea] custom infix functions

2016-04-22 Thread Adrian Zubarev via swift-evolution
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

Re: [swift-evolution] Enhanced existential types proposal discussion

2016-05-20 Thread Adrian Zubarev via swift-evolution
Can we use `Any<…>` for protocol conformance like this:  protocol A: Any {} <— this makes a little sense, but I’d rather write protocol A: class {} instead protocol B: Any  <— this is confusing. One could argue we could apply B only on any UIView subclass which conforms

[swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

2016-05-20 Thread Adrian Zubarev via swift-evolution
This is a follow up proposal to SE-0095 which should be considered for Swift 3 if SE-0095 will be accepted. Here is the formatted draft: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/-ban-redundancy-in-any-existential.md Please provide your feedback in this thread,

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

2016-05-20 Thread Adrian Zubarev via swift-evolution
rd and has its own behavior distinct from the behavior of all generic types.  Making it stand out syntactically will help to make that clear. Austin On Fri, May 20, 2016 at 2:39 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: This is a follow up proposa

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

2016-05-20 Thread Adrian Zubarev via swift-evolution
I think you should submit this for review, but I also think you should take the part of your older proposal to add class support to Any<...> and submit it as a separate proposal. (I mean, the part where you can define things like "Any" or "Any".)

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

2016-05-20 Thread Adrian Zubarev via swift-evolution
Isn’t `Any` a typealias for `any<>`?  If so, we have to support `any<>`! :) Yes it is and SE-0095 will cause that all types implicitly conform to empty any<>. This still can be banned from any, A> because its useless and redundant. But is up to the core team to decide. --  Adrian

Re: [swift-evolution] [Discussion] Namespaces

2016-05-20 Thread Adrian Zubarev via swift-evolution
I don't support any mechanism that allows you to *require* the developer to use your (sub)module or namespace name as a prefix in all cases.  However, I *do* support allowing them to *choose* to use it for either stylistic reasons or to resolve ambiguity. I’m absolutely fine with your second

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

2016-05-20 Thread Adrian Zubarev via swift-evolution
ent from my iPad On May 20, 2016, at 4:39 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: This is a follow up proposal to SE-0095 which should be considered for Swift 3 if SE-0095 will be accepted. Here is the formatted draft: https://github.com/DevAndArtis

Re: [swift-evolution] [Discussion] Namespaces

2016-05-20 Thread Adrian Zubarev via swift-evolution
I personally dislike the habit of deliberately naming different classes using the same name within a single project/module/library, just using different namespaces - one should be able to deduct from the code *which* class is being used without excessive checking. When you have namespaces Car

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

2016-05-21 Thread Adrian Zubarev via swift-evolution
Fair enough.  But in that case I think we want something that does exactly that: rejects classes, rather than indicating value semantics.  We need to do this in a way that doesn’t lead to a situation where we used the word `value` to mean “value type”, and later we have the capability to very

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

2016-05-21 Thread Adrian Zubarev via swift-evolution
I am saying the latter. I prefer the lowercase keyword and uppercase 'typealias Any = any<>' Thats what I also would prefer. And as we speak in this thread here: any won’t be allowed because its useless and redundant to Equatable. --  Adrian Zubarev Sent with

Re: [swift-evolution] [swift-users] UnsafeMutablePointer in structs

2016-05-21 Thread Adrian Zubarev via swift-evolution
Thank you, actually I only was curious what will happen if I do because I couldn’t think of a way to check what will happen to the pointer. Lets see how the core team re-build Foundation types like NSData to Data struct. --  Adrian Zubarev Sent with Airmail Am 20. Mai 2016 bei 22:17:34, Dan

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

2016-05-21 Thread Adrian Zubarev via swift-evolution
Another thing to consider is that AnyObject currently has magic that allows any Objective-C method to be called upon it if Foundation is imported on an Apple platform. I think it may be desirable to have AnyObject become something like Any, and have a differently-named construct take the place

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

2016-05-23 Thread Adrian Zubarev via swift-evolution
iPad On May 21, 2016, at 7:42 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: Proposal was updated as an enhancement proposal to SE–0095. You can read the new draft here: https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposal

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

2016-05-23 Thread Adrian Zubarev via swift-evolution
, at 7:42 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: Proposal was updated as an enhancement proposal to SE–0095. You can read the new draft here: https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-

Re: [swift-evolution] Proposal: Finalization in protocol extensions and default implementations

2016-05-18 Thread Adrian Zubarev via swift-evolution
t; > On 18 May 2016 at 16:15, Matthew Johnson via swift-evolution > <swift-evolution@swift.org> wrote: >> >> On May 18, 2016, at 12:53 PM, Adrian Zubarev via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I’d like to revive this

Re: [swift-evolution] Enhanced existential types proposal discussion

2016-05-18 Thread Adrian Zubarev via swift-evolution
12:11 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote: On May 18, 2016, at 12:12 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: Okay now I feel like we’re merging everything we came up until now :D I’d love to see something like this

Re: [swift-evolution] Enhanced existential types proposal discussion

2016-05-18 Thread Adrian Zubarev via swift-evolution
So without any initial constraints how would one use this generic function?? extension UIButton: ProtocolA {} let button = UIButton() let shadowedButton: ProtocolA = UIButton() // creates a set of a least one element if the generic type could be inferred func unionIfPossible(_ a: T, _ b:

Re: [swift-evolution] Enhanced existential types proposal discussion

2016-05-18 Thread Adrian Zubarev via swift-evolution
are inline. On Wed, May 18, 2016 at 1:57 PM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: So without any initial constraints how would one use this generic function?? extension UIButton: ProtocolA {} let button = UIButton() let shadowedButton: ProtocolA = UI

Re: [swift-evolution] Enhanced existential types proposal discussion

2016-05-18 Thread Adrian Zubarev via swift-evolution
fine with your proposal now. =)  --  Adrian Zubarev Sent with Airmail Am 18. Mai 2016 bei 23:17:47, Austin Zheng (austinzh...@gmail.com) schrieb: I'm not sure what your objections actually are, but my responses are inline. On Wed, May 18, 2016 at 1:57 PM, Adrian Zubarev via swift-evolution

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

2016-05-21 Thread Adrian Zubarev via swift-evolution
Proposal was updated as an enhancement proposal to SE–0095. You can read the new draft here: https://github.com/DevAndArtist/swift-evolution/blob/classes_in_any_existential/proposals/-classes-in-any-existential.md @Austin: I used some peaces of your enhancement proposal and you’re co-author

Re: [swift-evolution] [Pitch] Add the sign method to the SignedNumberType protocol.

2016-05-22 Thread Adrian Zubarev via swift-evolution
Whoops didn’t check that your example worked as well :D --  Adrian Zubarev Sent with Airmail Am 22. Mai 2016 bei 10:27:17, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: This should do the trick: extension SignedNumberType { var sign: Self { if self

Re: [swift-evolution] [Discussion] Namespaces

2016-05-20 Thread Adrian Zubarev via swift-evolution
to use "Int" for A's Thing type, and "String" for B's Thing type, but I can't. Best, Austin On May 20, 2016, at 5:16 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: I want to revive this topic. Is there any technical reason why we can’

Re: [swift-evolution] [Discussion] Namespaces

2016-05-20 Thread Adrian Zubarev via swift-evolution
Can submodules enforce the developer to use its name ’Submodule.SomeClass’? Do I have to re-build submodules when I made any changes to them before building the outside code base? Can they efficiently used for cross decencies between different modules/submodules? ——  Empty enums is an abuse of

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

2016-05-20 Thread Adrian Zubarev via swift-evolution
I don't understand what you mean.  I definitely think your 'typealias ABC = Any' should be valid. I said typealias ABC = Any is valid. Where typealias AliasA = Any is not and furthermore typealias AliasAA = Any should also not be valid because Any shouldn’t be valid. IMO

Re: [swift-evolution] [Discussion] Namespaces

2016-05-20 Thread Adrian Zubarev via swift-evolution
On May 20, 2016, at 10:54 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: Can submodules enforce the developer to use its name ’Submodule.SomeClass’? Ideally we would have flexible import syntax that allows for control over *how* names are imported into a l

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

2016-05-20 Thread Adrian Zubarev via swift-evolution
On May 20, 2016, at 11:03 AM, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote: I’m referring to this talk form the SE-0095 thread: My feedback is that we should narrow what is acceptable for Any as much as possible, because relaxing restrictions in the future won’t br

Re: [swift-evolution] [Proposal] Disallow redundant `Any<...>` constructs

2016-05-20 Thread Adrian Zubarev via swift-evolution
fter Swift 3 drops this will break code again, which we want to avoid, am I right? --  Adrian Zubarev Sent with Airmail Am 20. Mai 2016 bei 17:40:03, Matthew Johnson (matt...@anandabits.com) schrieb: On May 20, 2016, at 10:19 AM, Adrian Zubarev via swift-evolution <swift-evolution@swif

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

2016-05-19 Thread Adrian Zubarev via swift-evolution
Austin do we really need this 3rd proposal? This makes my original one really a waste of time. I was trying to solve https://openradar.appspot.com/20990743  with the original `Any<>` proposal when Swift 3 ships. Your other proposal would enhance it without introducing breaking changes. To that

Re: [swift-evolution] [Pitch] Rename protocol<> to Any<>

2016-05-19 Thread Adrian Zubarev via swift-evolution
I assume you meant to use Any and not protocol above. No, I was wondering why Any> would create a warning whereas protocol does not today. They can all be interpreted, but: - they provide multiple ways of expressing the same concept - the additional uses of Any detract from code

  1   2   3   4   5   6   7   8   >