Status of Silver

[hurden (Taras Vozniuk)]

@ck:

@ck

Subclassing classes with generic parameters. (most wanted: AsynchTask) - you cannot override existing methods that have generic parameters or return values, or you cannot provide the implement for the methods in abstract parent class that has generics.

You can. Just have to do the types right. I did improve the error message.

Please refer to the issue: How to override generic method in silver?
Which is not fixed yet. You don’t just have to do types right, you need some kind of wizardry then if the there is no way you can override the method that returns on takes generic type T, which is exactly what you need to do to subclass the AsynchTask

@ck

Ability to conform to generic protocols

Pretty sure that works?

Open the Intenger_Extensions in SwiftBaseLibrary and try making anything to conform to these Equatable, Strideable and so on protocols. You will see that your protocol implementation as an extension of any of these base type won’t be found.

@ck

The error in do { } catch { } is of Exception type, not Object.

Why is this a problem? On .NET the root type of exceptions IS Exception (Throwable on Java).

Not a big deal but because I had aliased Exception and ErrorType to Error

#if COOPER
public typealias Error = java.lang.Exception
#else
public typealias Error = ErrorType
#endif

when I write the shared Silver/Swift code and in catch I would pass back the completion handler I always need to use as! in Fire in order to compile and since code is shared, xCode will give me unnecessary warning.

@ck

Allow putting try before the constructor call.

Not allowed on .NET and Java.

Can you make try to be no-op there, just so that no #if COOPER #else #endif won’t be needed for throwing inits.?

Can you share any estimate on when we can expect the following issues will be fixed?

1. Silver: Self? in protocols results in inability to conform to them
2. How to override generic method in silver?
3. Struct Types conforming to protocols, Conforming to protocols that contain associated types in function signatures

I just would be really glad if the protocol stuff will be fixed so to certain extend Swift Base Library can be mirrored in Silver with Silver numerical types conforming to protocols that Swift numerical types do, so that the use of generic constraints will be Swift/Silver consistent.