On Monday, 22 August 2022 at 16:42:50 UTC, Paul Backus wrote:
It's probably not worth completely changing your API design
just to work around this issue. Also, even if you do this, it
is still possible for a user to run into a same problem with a
member function of one of their own types; for example:
```d
import your.library;
struct MyStruct {
U myFunc() { /* ... */ }
}
@(MyStruct.myFunc) whatever;
```
This will be users' issue then, not mine :)
I'm providing a struct (`U` in examples above) with some API and
I'm looking for this struct as an UDA (through
`hasUDA`/`getUDAs`). And actually I already have a mix of
member-functions and free-functions in my API so it's gonna be
more consistent if I make all of them free-functions.