[swift-evolution] Proposal: CustomConvertible protocol

Jeremy Pereira jeremy.j.pereira at googlemail.com
Fri Dec 4 10:09:24 CST 2015


> On 4 Dec 2015, at 14:27, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:
> 
> I know that, but I couldn’t describe it better. I mean implicit casts are already there and do look the same:
> 
> class A {}
> class B: A {}
> 
> let someA: A = B() // this works fine
> 
> protocol C {}
> 
> class D: C {}
> 
> let someC: C = D() // this works fine too

Neither of these are casts. someA is actually  a reference to the B. someC is a reference to a D (I’m not sure how the mechanism worked for structs conforming to protocols, but there’s still no instance conversion) 


> 
> Sure it depends on the context, but the implicit cast functionality could be extended on my opinion. 
> 
> I build a little prototype to be able to automatically cast math expression. It looks something like this:
> 
> let someDouble = Double(UInt(0) + Int(1)) // + is overloaded
> 
> // sometimes the compiler complains so I need to write this  
> 
> let someDouble = Double(UInt(0) + Int(1) as Expression)
> 
> // it would look better if we had implicit conversion enabled trough constructors
> let someDouble: Double = UInt(0) + Int(1)
> 
> // or
> let someDouble: Double = UInt(0) + Int(1) as Expression
> 
> 

This used to come up on the Apple lists. A deliberate design decision was taken early on to require explicit conversion for arithmetic types on the grounds that implicit casts are a common source of error. I don’t think any proposal to add them back in is going to get very far.


> 
> 
> 
> 
>> Regards Adrian
> 
> Am 4. Dezember 2015 bei 15:15:59, Stepan Hruda (stepan.hruda at gmail.com) schrieb:
> 
>> This is not how *LiteralConvertible protocols work, though. You can only initialize variables with specific literal values recognized by the parser, it never magically casts a type to a different type for you. Similar implicit casts in my opinion confuse whoever reads the code afterwards.
>> 
>> ```
>> class SomeConvertible: BooleanLiteralConvertible {
>>     typealias BooleanLiteralType = Bool
>>     let boolean: Bool
>> 
>>     internal required init(booleanLiteral value: SomeConvertible.BooleanLiteralType) {
>>         self.boolean = value
>>     }
>> }
>> 
>> func getBoolean() -> Bool {
>>     return false
>> }
>> 
>> let validConvertible: SomeConvertible = false
>> // Line below doesn’t compile
>> let invalidConvertible: SomeConvertible = getBoolean()
>> ```
>> 
>> 
>> 
>> 
>> On Fri, Dec 4, 2015 at 8:51 AM, Adrian Zubarev <adrian.zubarev at devandartist.com> wrote:
>> 
>> We have finally a corner where people can share their ideas on how Swift can be improved, and I’m glad my ideas might be part of this fun.
>> 
>> Swift introduced a few Convertible protocols, but it still needs some more If you ask me.
>> 
>> Something like this:
>> 
>> public protocol CustomConvertible {
>>       
>>     typealias CustomType
>>       
>>     public init(value: Self.CustomType) // or in a better way I can't come up with
>> }
>> 
>> 
>> But it should work in a way that we could create more different types like enums and ErrorType.
>> 
>> protocol AConvertible: CustomConvertible { /* some stuff here*/ }
>> protocol BConvertible: CustomConvertible { /* some stuff here*/ }
>> 
>> struct A {
>>     var foo: Int = 0
>> }
>> 
>> struct B {
>>     var boo: String = "Hello World"
>> }
>> 
>> struct C: AConvertible, BConvertible {
>>       
>>     typealias CustomAType = A
>>     typealias CustomBType = B
>>       
>>     var magical: SomeType
>>           
>>     init(value: CustomAType) {
>>         // implement it
>>     }
>>       
>>     init(value: CustomBType) {
>>         // implement it
>>     }
>> }
>> 
>> //===========================
>> 
>> let firstC: C = A() // this is what I'm missing in Swift
>> let secondC: C = B() // this would be a great syntax sugar
>> 
>> 
>> What do you think?
>> 
>> 
>> 
>>>> Regards Adrian
>> 
>> 
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list