- this looks like a workaround to a missing compiler feature; but could this be implemented better?
What about VARPTR( array )? Any conflicts or ambiguity?
Fxm´s code is a clever workaround for a missing feature. Currently you can use VARPTR for retrieving a pointer to an array´s elements, but you cannot retrieve the array´s descriptor with VARPTR. I already coded the necessary changes for the compiler to return this pointer with VARPTR: p = @array, or p = VARPTR(array). It implements the same syntax as U/LBOUND: array variable without index. As far as i can tell, fxm´s structure definition here for the array descriptor is correct.
Before making a new pull request i would like to know, what would be the preferred/best way of implementing the new array features (sort, insert, delete). I see three ways to go:
1.) as is - add it as include file (definitions and run time code in array.bi). The features are available only, if array.bi is included. This makes everything acessible to the user.
2.) add only the definitions to array.bi, and add the code to the runtime library, which still requires array.bi to be included for making the features available (just like file.bi). This keeps parts of the low level stuff away from the user
3.) add it to the compiler (new keywords etc.) and add the actual code to the runtime library, which makes an include file (array.bi) obsolete. This keeps all the low level stuff away from the user
Obviously #1 is easiest and compared to other features not an unusual way. What do you think, how should i procede?