I also don't think this is a worthy change. Mirror can be extended or even changed in the future to become a true reflection base class. No benefits added and breaking code are to me a reason to not go forward with this.
L On 21 July 2016 at 22:05, Anton Zhilin via swift-evolution <swift-evolution@swift.org> wrote: > Somehow I did not send a copy to evolution the first time: > > I have to agree. Stopping the discussion on this until after Swift 3. > > And response from Dmitri: > > Thanks! > > Just wanted to be clear -- I am not against reflection. And I am > concerned whether the current design of Mirror will work for the > long-term full-featured reflection implementation, but only because we > don't know what will be the shape of reflection in Swift. For > example, would we be able to call arbitrary public functions on a type > by name? If yes, how would that be implemented -- both in the API, > and on the low level, how would actual function call and argument > passing work? How much extra metadata and thunks would the compiler > need to emit? Would an average app or framework want that bloat? > Remember that we don't have a JIT, so we can't say "we will do what > Java (or any other mainstream language with reflection) does", because > we can't. > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution