Getters/setters generator

[Eugene Wissner via Digitalmars-d-announce]

On Tuesday, 13 June 2017 at 21:49:53 UTC, jmh530 wrote:
> On Tuesday, 13 June 2017 at 20:45:34 UTC, jmh530 wrote:
>>
>> Fair point. I just was playing around with it today and was 
>> like, oh that's pretty easy. It was only when I was trying to 
>> see if anyone else had done anything like this that I came 
>> across your project.
>
> I was just looking at the code in the package. There was an 
> earlier discussion on predicates. If you changed the 
> Read/RefRead/etc structs to be something like below, then the 
> user could add in a string of the assert. It's not really all 
> that elegant, but I think you should be able to get it to work.
>
> struct Read
> {
> 	string visibility = "public";
> 	string constraint = void;
> }
>
> My ideal was to get something working where the lower and upper 
> bounds were actual values, so you didn't have to pass the 
> string, but I can see how that gets complicated. One problem I 
> ran into is that you can't really make a struct templated in an 
> optional way. For instance, the following won't compile 
> (ignoring the complexity of making the asserts > or >=):
>
> struct Read(T = void)
> {
> 	string visibility = "public";
> 	static if (!is(T == void)) {
> 		T lower;
> 		T upper;
> 	}
> }
>
> void main()
> {
> 	Read read;
> }

I think that predicates aren't predicates for specific types 
(like lower/upper for arithmetic types), but generic predicates 
that could replace in/out constraints. For example lower/upper 
boundaries could be expressed then as "x >= a && x < b".

Now it isn't clear what should happen if the predicate doesn't 
hold (do we use enforce and throw an exception or assert and 
throw an error). Ok, it can be solved with template parameter for 
the GenerateFieldAccessors mixin).

String constraints are imho ugly and error prone. For example I 
personally don't use alogrithms like sort with string predicates, 
but only with lambdas.

Maybe it is possible to pass a lambda to the struct that gets a 
value of the member and evaluetes to a boolean - I haven't tested 
it. But even with a lambda it doesn't look thaaaaat cool:

@ConstRead @Write(ref x => x > 0 && x < 10)