property API design

[Richard (Rikki) Andrew Cattermole]

On 13/09/2026 9:41 AM, DanielG wrote:
> I'm currently wrapping a C++ API, and there are implicit properties in 
> the API surface (getter and setter), but the getter naming is inconsistent.
> 
> The setters are always `setProperty`, but getters can be:
>    - `T someProperty()`
>    - `bool isSomeProperty()`
>    - `bool hasSomeProperty()`
> 
> In writing my D wrapper for this, I'm hesitant to hide the original API 
> entirely - not least because I would prefer people can consult the C++ 
> documentation to see what methods should be called, without having to 
> read with a fine-tooth comb to figure out whether something is a 
> property or not (and thus having to omit `is`/`has`/`set` prefixes).
> 
> Often a class will have a dozen `setXXX` methods - some of them 
> properties, some not. Seems a bit cruel to make half of them disappear, 
> because they're property setters (requiring `.XXX = value` syntax instead)
> 
> **So my question is this:** would the following be acceptable in my D 
> bindings? Would this lead to any annoying/weird problems later on?
> 
> ```d
>      bool isSomeProperty() { ... }
>      void setSomeProperty(bool value) { ... }
>      @property alias someProperty = isSomeProperty;
>      @property alias someProperty = setSomeProperty;
> ```
> 
> On the surface this seems like a nice way to make using the API less of 
> a chore. Property syntax if you want it, identical C++ syntax if not.

Forget @property, that's on the kill list as it doesn't do anything 
useful for properties and all attempts to get it doing something useful 
have failed. Otherwise its a fine idea.