3 ms·

I don't get what's wrong with his post about reflection, why would someone be uncomfortable with a tool? https://soasis.org/posts/a-mirror-for-rust-a-plan-for-

by taosx 3y ago

I don't get what's wrong with his post about reflection, why would someone be uncomfortable with a tool? https://soasis.org/posts/a-mirror-for-rust-a-plan-for-generic-compile-time-introspection-in-rust/ https://soasis.org/posts/a-mirror-for-rust-a-plan-for-generi... - Is this the post ?

junon 3y ago
Right. I didn't realize it was that sort of reflection, see my edit. I don't know if their approach is the right one. I think the visitor pattern is a bit limited in usefulness (where it fits nicely for serde, it'll fall flat for other more exotic use cases I think. But I've not thought about it for more than about 5 minutes and haven't considered any other possible alternatives - they have.) However, I agree with them in that the current song and dance with syn being the prevailing defacto crate most of our macros are built on is a bit absurd, especially since they refuse to open up proc_macro internals for use by the public. I can certainly see both sides' points but the net effect is that, right now, the macro business yields subpar error handling and feels very much hacked on rather than being a natural part of the language like most other things in Rust seem to.
sanderjd 3y ago
I don't get it at all. Why would this would be inappropriate to cover in a keynote. Whether or not it ends up in the language, it's interesting material. It seems like it may be a case of people taking themselves too seriously; "we can't have that topic in our precious keynote!". Nobody cares!
deleted 3y ago
[deleted]
ahahahahah 3y ago
I think it would be totally reasonable for a core member to say something like, "I'm uncomfortable with a keynote about this compile time reflection from Person1. I think it could look like we're endorsing it more than we are prepared for." That's exactly how I might think and talk about some extensive complex proposal from some outsider for a problem that I have some ideas on how we might want to solve. All the people upset about the keynote changes describe it in such like exaggerated form, that to me it's hard to just believe that they are the reasonable ones here.

by taosx 3y ago

junon 3y ago

Right. I didn't realize it was that sort of reflection, see my edit. I don't know if their approach is the right one. I think the visitor pattern is a bit limited in usefulness (where it fits nicely for serde, it'll fall flat for other more exotic use cases I think. But I've not thought about it for more than about 5 minutes and haven't considered any other possible alternatives - they have.) However, I agree with them in that the current song and dance with syn being the prevailing defacto crate most of our macros are built on is a bit absurd, especially since they refuse to open up proc_macro internals for use by the public. I can certainly see both sides' points but the net effect is that, right now, the macro business yields subpar error handling and feels very much hacked on rather than being a natural part of the language like most other things in Rust seem to.

sanderjd 3y ago

I don't get it at all. Why would this would be inappropriate to cover in a keynote. Whether or not it ends up in the language, it's interesting material. It seems like it may be a case of people taking themselves too seriously; "we can't have that topic in our precious keynote!". Nobody cares!

deleted 3y ago

[deleted]

ahahahahah 3y ago

I think it would be totally reasonable for a core member to say something like, "I'm uncomfortable with a keynote about this compile time reflection from Person1. I think it could look like we're endorsing it more than we are prepared for." That's exactly how I might think and talk about some extensive complex proposal from some outsider for a problem that I have some ideas on how we might want to solve. All the people upset about the keynote changes describe it in such like exaggerated form, that to me it's hard to just believe that they are the reasonable ones here.