[swift-evolution] Conditional casting and conditional binding: Wierd edge case or flawed design

Normally in guard and if condition lists, you look up a value in a dictionary and conditionally cast: if let value = dict[key] as? T, ... The "as?" operator passes the Any? type through, and the lhs result is T, not T?. * dict[key] returns Any? * Any? as T returns T?, not T?? * the

[swift-evolution] [proposal] Allow convenience initializers to use "self = Foo()"

Does anyone else think we should allow assignment to self in Class "convenience init" methods? Ie: this is legal for a struct, but complains about self being immutable if you try it in a Class, even if it's a convenience init: init( foo:String ){ self = Me( bar:foo ) } I haven't

Re: [swift-evolution] private & fileprivate

> On 09 Oct 2016, at 19:22, Daniel Tartaglia via swift-evolution > wrote: > > the programer specifies exactly which methods can be used by which classes. That IMO is the only sensible solution. Everything else -even in the name of simplicity- will be insufficient

Re: [swift-evolution] private & fileprivate

That sounds absolutely horrible. Keep building walls and ultimately you'll never leave your bike shed. On Oct 9, 2016 1:23 PM, "Daniel Tartaglia via swift-evolution" < swift-evolution@swift.org> wrote: > This discussion reminds me of Eiffel’s access system. Instead of having > these generic

Re: [swift-evolution] private & fileprivate

This discussion reminds me of Eiffel’s access system. Instead of having these generic “public/private” distinctions, in Eiffel the programer specifies exactly which methods can be used by which classes. So a “public” method would be defined as accessible to “[Any]” and a private method would be

Re: [swift-evolution] [Proposal] Enums with stored properties

I would love to be able to have stored properties in addition to the varying elements. Now, I end up creating a secondary struct T and doing case a(T, whatever), b(T, whatever), c(T, whatever), etc. where the same associated structure is every case, *or* I end up putting the enum into a

Re: [swift-evolution] stored properties in extensions (was: associated objects)

No, I've also suggested how it would be implemented. It would, as I've described, require support from the compiler and runtime - the protocol conformance would tell the compiler to include an extra space in the instance layout for [AnyHashable : Any], which would get to be used by the runtime

Re: [swift-evolution] Conditional casting and conditional binding: Wierd edge case or flawed design

A quick fix: guard let value = dict["Key"].map({ $0 as NSString }) { use(value) } Current behavior is quite logical: main purpose of as? is to perform casts, which are not guaranteed to succeed. But I’d say that as? should also support what you want. ​

Re: [swift-evolution] Conditional casting and conditional binding: Wierd edge case or flawed design

If you'd like more context to the conversation: How do I: Cast an optional string to NSString -- E > On Oct 9, 2016, at 6:59 PM, Anton Zhilin wrote: > > A quick fix: > > guard let value

[swift-evolution] [Pitch]Building a limited framework to develop Android Apps in Swift 3.0

In Swift 3.0 you can build Android apps in Linux but only console apps as there is no framework to build GUI apps using JNI. What I propose is to build an initial limited framework coded in C that calls enough of the Java Android API via JNI to bootstrap the android app and to create widgets and

Re: [swift-evolution] stored properties in extensions (was: associated objects)

*Replace both instances of “class C: P” with just “class C” since the conformance comes in the extension. That’s what I get for writing this quickly. Charles > On Oct 9, 2016, at 3:43 PM, Charles Srstka wrote: > > protocol P { > var foo: String { get } >

Re: [swift-evolution] [Proposal] Enums with stored properties

Mateusz, To me, "Enumeration defines a type with well defined set of possible values" seems to contradict the idea of having properties that can have different values. What could you do with this special enum - what would the code that uses it look like? On Sun, 9 Oct 2016 at 04:56 Robert

Re: [swift-evolution] [proposal] Allow convenience initializers to use "self = Foo()"

Not good. In classes, we can’t always determine the exact type of "self”. In subclasses of “Me”, such an assignment would not work. Something like `self = Self(bar: foo)` could work, but that exact case is exactly the same as `self.init(bar: foo)`. I would still appreciate being able to do

Re: [swift-evolution] stored properties in extensions (was: associated objects)

I have been thinking further on this and in addition to my previous two thoughts about implementation, I have had another idea... 3. If there is a bit spare in the object header somewhere (that is currently always zero), this could be used to signify the presence of an additional struct that

Re: [swift-evolution] stored properties in extensions (was: associated objects)

There is a 4th way. Introduce an internal protocol Associatable, which would tell the compiler to add an additional (hidden) field to the object which would include the "dictionary" of key -> value associated values. (It would be off-limits to extensions, of course). This way: - it won't be

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Charlie, What you suggest defines how you would use it from your code, not how it would be implemented in the language. If you look at my AO implementation it does what you say: https://github.com/j-h-a/AssociatedObjects/blob/develop/AssociatedObjects/AssociatedObjects.swift i.e. has a protocol

Re: [swift-evolution] stored properties in extensions (was: associated objects)

Charles, That would be good. It is a nicer way to write what is already possible to achieve, but it's not a way to 'implement' stored properties in extensions. On Sun, 9 Oct 2016 at 21:45 Charles Srstka wrote: > *Replace both instances of “class C: P” with just “class

Re: [swift-evolution] stored properties in extensions (was: associated objects)

How about a 5th way? 5. Let extensions introduce stored properties, but only in the same module as the type’s definition. Then, the compiler can just take any extensions into consideration when it’s determining the size of the type, just as if the properties had been declared in the type.