Comments (8)
I don't like piling new and new attributes into this crate
yeah, I agree. at this point, I also felt the heavy annotation is overwhelming and the added noise might already over weighted the benefit of using macros to reduce boilerplates. it's definitely not the right direction to go to make the library over complicated. my initial motivational use case was a one-off situation anyway.
I think it's good to close this for now; maybe we can re-open it if the idea gets clearer and more mature.
from rust-delegate.
I suppose that the question mark operator is common enough to warrant a special attribute. But at this point, I wonder if we should just create some generic expr wrapper, like
struct Wrapper(Foo);
impl Wrapper {
delegete! {
#[expr(Ok($expr?))]
to self.0 {
fn foo(&self) -> Result<..., ...>;;
fn bar(&self) -> Result<..., ...>;
}
}
}
from rust-delegate.
I wonder if we should just create some generic expr wrapper, like
I like the idea of a generic solution. as for the syntax of the placeholder $expr
, I think a shorter sigil is enough, like a single $
sign or something. on the other hand, $expr
is more extensible (to support potential new features). I don't really know which way I like more, maybe you have better ideas in mind?
from rust-delegate.
I guess that it will depend on what will be the easiest to parse with syn
, I'm not even sure if we can start the sigil with $
. I'm leaving for a two week vacation now, so I won't be able to work on this now, I'll experiment with it in September.
from rust-delegate.
Hmm, $
nor $expr
can be parsed as an expression with syn
. And also I realized that this would clash with the to <expr>
target expression a little bit. Ideally we would be able to say something like delegate! { to Ok(self.foo.$call) }
, but this conflates two things - the target of the call (self.foo
) and an additional "wrapping" expression around the resulting call (Ok(...)
). And also this syntax wouldn't work, because sometimes the call can be performed with ::
instead of .
(for associated functions).
from rust-delegate.
delegate! { to Ok(self.foo.$call) }
yeah, too much is going into a single syntax form, and that looks complicated to me. it would be good for a general solution, but I think for now, make the question mark operator a special case is acceptable.
my first thought was maybe we can decorate the function signature a little bit, similar to how function parameters can be transformed in current version, something along the lines of:
delegate! {
to self.0 {
// this syntax?
pub fn foo(&self, #[into] other: Self) -> #[Ok(?)] Result<isize, Self::Error>;
// or this?
pub fn foo(&self, #[into] other: Self) -> #[map_err] Result<isize, Self::Error>;
// or even this?
pub fn foo(&self, #[into] other: Self) -> ? Result<isize, Self::Error>;
// but it feels too complex if we want to fit too much features
pub fn foo(&self, #[into] other: Self) -> #[ok_or(Error::DataEmpty)] Result<isize, Self::Error>;
}
}
looking into the documents, I find that currently we support #[unwrap]
, #[try_into]
, #[into]
, I think it would be reasonable to add the opposite of #[unwrap]
, I don't have a suitable naming yet, maybe something like #[Ok]
and #[Some]
, (and by extension, an variant form like #[Ok(?)]
, although it would be useless for a #[Some(?)]
), this should coverage the common use cases of the form Ok(self.inner.foo()?)
I think.
from rust-delegate.
I'm still unsure about this, as I don't like piling new and new attributes into this crate. I think that some experimentation with the placeholder syntax (like #[wrap(Ok(_)?)]
) could be nice, but I don't currently have time to play with it. I'd be happy to accept PRs where we could discuss a specific implementation though :)
from rust-delegate.
Ok :) Closing for now.
from rust-delegate.
Related Issues (20)
- 0.5.0 fails to compile
- Delegate with additional arguments
- Transfer ownership! HOT 3
- Bridging sync to async gap with delegate HOT 5
- Allow #[from] and #[into] annotations, pattern-matching or even arbitrary transformation functions for delegated arguments HOT 10
- allow #[try_from] and #[try_into] HOT 8
- Is delegating to enum in the target range HOT 4
- Compatability with async_trait HOT 2
- Just unwrap HOT 3
- Assign Return Value Of Delegated Calls To Delegated Field HOT 7
- Add attribute to the return value of all methods HOT 4
- Add support support for qualified calls HOT 6
- Delegate to Self HOT 1
- New release? HOT 1
- Change default inlining mode
- `no_std` support HOT 3
- Possible to support delegation of Constructors? Fuctions returning `Self` and `Result<Self, SomeErr>`? HOT 4
- Re-use documentation from delegated method HOT 2
- Support for delagating to enum variants with different inner type and `#[into]` modifier. HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust-delegate.