Closed lundmark closed 6 years ago
Yeah... These are possible solutions. If there weren't the backwards compat issues the type- solution sounds best.
There is also the possibility of just always skipping const on pointers? Do the constness really bring something here?
And if we can determine that const here is not that big of a gain we can just skip it and add const-support to the type param.
Well tbh, I think that pointers should be none-const unless specified. It feels like the most intuitive interface. However, that does break backward compability. I don't really see the need for it to be a specific flag though so I think that having it in the type declaration is maybe more intuitive?
The more I think about it the more I agree with adding const to "type". It should not be something that dl should decide for you if a type is const or not. Except for maybe string?
It is decided, let's remove const and add it to type!
This should probably be closed now?
Closed and replaced by #89
As discussed earlier:
We have the need to use both const-pointers and none-const pointers as members in structs.
Currently I have a local implementation that simply supports the member option "const" : true/false.
It is default to true. Is this the best solution or do we want to go with: "type": "const t" / "type": "t"?
If we want my flag-implementation I can fix a pull-request fairly quick.