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.

Reply via email to