I agree with Dmitri. I would rather see a proper design for reflection (similar to Completing Generics) before we start making any changes to the existing machinery.
Best, Austin On Thu, Jul 21, 2016 at 4:39 PM, Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote: > On Thu, Jul 21, 2016 at 4:06 PM, Anton Zhilin <antonyzhi...@gmail.com> > wrote: > > 2016-07-22 1:34 GMT+03:00 Dmitri Gribenko <griboz...@gmail.com>: > >> > >> > Mirror.DisplayStyle contains optional and set as special cases, but > does > >> > not > >> > contain function > >> > Mirror collects all information possible at initialization, while for > >> > true > >> > reflection we want laziness > >> > Mirror allows customization. For example, Array<T> is represented > with a > >> > field for each of its elements. Do we want this for “true” reflection > we > >> > want to add in the future? > >> > >> Why can't we add these features to Mirror in future? > > > > > > Reflection in some other languages works as follows: we have a type > (let's > > name it 'Reflection'). Each instance of it contains ID of one type and > can, > > for example, retrieve an array of its static or normal methods. > > I understand. But we don't know how reflection will work in Swift, we > haven't designed it yet. You are assuming it will work like it does > in other languages, which will not necessarily be the case. > > > Moreover, types can completely customize contents of their > > 'Mirror's. This is incompatible with laziness and with how reflection > should > > work, based on experience from other languages. > > That is actually viewed as a weakness of reflection in other > languages. Allowing reflection to access other types' internal data > and APIs creates barriers for optimization, and facilitates creating > binary compatibility problems when apps include code that uses > reflection to poke at internal data of library types. > > Dmitri > > -- > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <griboz...@gmail.com>*/ > _______________________________________________ > 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