Starter project: Remove old mirrors

Hi,

If someone is interested in working on a simple and useful starter
project, here is one.

We need to remove old mirrors from the standard library and the runtime.

The first step is very simple: all old mirrors in the standard library
and SDK overlays should be migrated to the new CustomReflectable APIs.
All mirrors that didn't have tests and are affected by this conversion
should get tests.

The dump() function needs to be rewritten to use new mirrors.

We need new runtime entry points that make sense for the new mirror
implementation. The current entry points (the _reflect() function and
all its implementation details) directly depend on the old mirrors.
This step is slightly harder, but not doesn't require extraordinary
skills. This part requires writing a proposal, because the runtime
API is going to be stable.

This project is tracked by [SR-88] Remove old mirrors · Issue #42710 · apple/swift · GitHub

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 <gribozavr@gmail.com>*/

I'd be interested in working on this, if nobody else minds.

Austin

···

On Sun, Dec 6, 2015 at 2:20 AM, Dmitri Gribenko via swift-dev < swift-dev@swift.org> wrote:

Hi,

If someone is interested in working on a simple and useful starter
project, here is one.

We need to remove old mirrors from the standard library and the runtime.

The first step is very simple: all old mirrors in the standard library
and SDK overlays should be migrated to the new CustomReflectable APIs.
All mirrors that didn't have tests and are affected by this conversion
should get tests.

The dump() function needs to be rewritten to use new mirrors.

We need new runtime entry points that make sense for the new mirror
implementation. The current entry points (the _reflect() function and
all its implementation details) directly depend on the old mirrors.
This step is slightly harder, but not doesn't require extraordinary
skills. This part requires writing a proposal, because the runtime
API is going to be stable.

This project is tracked by [SR-88] Remove old mirrors · Issue #42710 · apple/swift · GitHub

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 <gribozavr@gmail.com>*/
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Note that I'm already working on this part. The Swift runtime needs to provide low-level reflection interfaces that allow the standard library to implement Mirror without depending on private runtime ABI.

-Joe

···

On Dec 6, 2015, at 2:20 AM, Dmitri Gribenko via swift-dev <swift-dev@swift.org> wrote:

We need new runtime entry points that make sense for the new mirror
implementation. The current entry points (the _reflect() function and
all its implementation details) directly depend on the old mirrors.
This step is slightly harder, but not doesn't require extraordinary
skills. This part requires writing a proposal, because the runtime
API is going to be stable.

Note that I'm already working on this part. The Swift runtime needs to

provide low-level reflection interfaces that allow the standard library to
implement Mirror without depending on private runtime ABI.

That's great to hear! Is there any chance that this work could introduce
type-level reflection APIs that would allow reflecting uninstantiated
types? Or should I make a formal proposal for this functionality in
swift-evolution?

···

On Mon, Dec 7, 2015 at 9:01 AM, Joe Groff via swift-dev <swift-dev@swift.org > wrote:

> On Dec 6, 2015, at 2:20 AM, Dmitri Gribenko via swift-dev < > swift-dev@swift.org> wrote:
>
> We need new runtime entry points that make sense for the new mirror
> implementation. The current entry points (the _reflect() function and
> all its implementation details) directly depend on the old mirrors.
> This step is slightly harder, but not doesn't require extraordinary
> skills. This part requires writing a proposal, because the runtime
> API is going to be stable.

Note that I'm already working on this part. The Swift runtime needs to
provide low-level reflection interfaces that allow the standard library to
implement Mirror without depending on private runtime ABI.

-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

You should propose any new functionality you'd like to see. Our first goal necessarily has to be to support the functionality that already exists.

-Joe

···

On Dec 7, 2015, at 12:21 PM, Jean-Pierre Simard <jp@jpsim.com> wrote:

> Note that I'm already working on this part. The Swift runtime needs to provide low-level reflection interfaces that allow the standard library to implement Mirror without depending on private runtime ABI.

That's great to hear! Is there any chance that this work could introduce type-level reflection APIs that would allow reflecting uninstantiated types? Or should I make a formal proposal for this functionality in swift-evolution?

Hi Jean-Pierre,

> Note that I'm already working on this part. The Swift runtime needs to provide low-level reflection interfaces that allow the standard library to implement Mirror without depending on private runtime ABI.

That's great to hear! Is there any chance that this work could introduce type-level reflection APIs that would allow reflecting uninstantiated types? Or should I make a formal proposal for this functionality in swift-evolution?

There is a proposal for uninstantiated type metadata reflection in the GitHub repo in docs/proposals/RemoteMirrors.rst, but it might not cover your specific use-case. As Joe hinted, starting from concrete requirements is the best way forward here.

Slava

···

On Dec 7, 2015, at 12:21 PM, Jean-Pierre Simard via swift-dev <swift-dev@swift.org> wrote:

On Mon, Dec 7, 2015 at 9:01 AM, Joe Groff via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

> On Dec 6, 2015, at 2:20 AM, Dmitri Gribenko via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>
> We need new runtime entry points that make sense for the new mirror
> implementation. The current entry points (the _reflect() function and
> all its implementation details) directly depend on the old mirrors.
> This step is slightly harder, but not doesn't require extraordinary
> skills. This part requires writing a proposal, because the runtime
> API is going to be stable.

Note that I'm already working on this part. The Swift runtime needs to provide low-level reflection interfaces that allow the standard library to implement Mirror without depending on private runtime ABI.

-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Thanks for sharing that, Slava! Reading that really helped me gain a better
understanding of how the current reflection model works and how it could be
extended.

Although my intended use cases are more for in-process type-level
reflection akin to objc_copyClassList and class_copyPropertyList.

In any case, swift-dev isn't the best place to discuss this, so I'll
synthesize my thoughts into a swift-evolution proposal shortly.

···

On Mon, Dec 7, 2015 at 11:51 PM, Slava Pestov <spestov@apple.com> wrote:

Hi Jean-Pierre,

On Dec 7, 2015, at 12:21 PM, Jean-Pierre Simard via swift-dev < > swift-dev@swift.org> wrote:

> Note that I'm already working on this part. The Swift runtime needs to
provide low-level reflection interfaces that allow the standard library to
implement Mirror without depending on private runtime ABI.

That's great to hear! Is there any chance that this work could introduce
type-level reflection APIs that would allow reflecting uninstantiated
types? Or should I make a formal proposal for this functionality in
swift-evolution?

There is a proposal for uninstantiated type metadata reflection in the
GitHub repo in docs/proposals/RemoteMirrors.rst, but it might not cover
your specific use-case. As Joe hinted, starting from concrete requirements
is the best way forward here.

Slava

On Mon, Dec 7, 2015 at 9:01 AM, Joe Groff via swift-dev < > swift-dev@swift.org> wrote:

> On Dec 6, 2015, at 2:20 AM, Dmitri Gribenko via swift-dev < >> swift-dev@swift.org> wrote:
>
> We need new runtime entry points that make sense for the new mirror
> implementation. The current entry points (the _reflect() function and
> all its implementation details) directly depend on the old mirrors.
> This step is slightly harder, but not doesn't require extraordinary
> skills. This part requires writing a proposal, because the runtime
> API is going to be stable.

Note that I'm already working on this part. The Swift runtime needs to
provide low-level reflection interfaces that allow the standard library to
implement Mirror without depending on private runtime ABI.

-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev