Those were some features, which MAY be interessting for the RO-Team to implement, idk I just wanted to list them up and mark them as disscusable
P.S Does actually inherit Oxygene the “ordinal-principle” of object-pascal, because a subrange of this, which was posseble in the older-pascal,"TAlphabet = 'A'..'Z' which means, create a own char-type, which just allows A to Z and none other charachter from ASCII/Ansi/UJnicode…
Or this was also possible back then: TEnum = enum(A, B, C,D) of Byte; TBla = TEnum.A..TEnum.C;
Which creates a type TBla, which just allows values between A and D (A,B,C,D)
Wow, ok first thx for the response of it, but unfortunately, I have to say, that the last of your answering is not supported and it is a very cool feature and i used it much in fpc back then and it is a helpful way to limit some possibilities without being concerned about the checking because the compiler does it
Also, the TAlphabet = ‘A’…‘Z’ doesnt work, it fails at compiletime
And for the openarrays, on the one hand it is right what you have said, but with one exception: the open_arrays in fpc were stack-allocated, so the function took ALSO stackallocated-arrays, which length was unknown to the compiletime, that was the good thing
Lastly, Its correct, that they are not often used, honestly, I asked because he will use some of this in the livestream he mentioned, to optimize something for the rendering process on the gpu… so I wanted actually to also make use of it and avoid some ugly workarounds of it, but what to do.
With the last paragraph I meant the “Bitfields of C”.
Ok cool
And am I still able to inspire you for the open-array stuff
Whats your opinion about that, because I said for clarity, that the fpc functions could also take stackalloc-arrays which currently isnt supported in island/oxygene, just dyn. arrays which are heap-based allocated.
Actually a really good thing for performance issues ofc
And AFAIK, I think that on the compiler-implementation-lvl this shouldnt be THAT MUCH, to create, because its just should accept undefined-array-length of a stack-array
I know that oxygene does support the static-array which you mentioned above, but:
I mean that oxygene doesnt support that a method, which can take ANY static-array, which length is unknown at compiletime, for instance:
method TakeAnySizedArray<T>(const any: array of T); //any MUST BE a static-array butit can be any-sized, nevermind if passing 5-elements-array, or 100-elements-array or 10000-elements-array,, so the function takes always a reference to stack-allocated-array!
Because how it is at the moment:
method TakeAnySizedArray<T>(const any: array of T); //any is a dynamic array!
Guys, what actually are ur feelings about named tuples ?
Because, that would totally kill all useless senseless dataholder-records which are doing nearly nothing but keeps some data and being used in some methods, but with the unfortunate need of their names, so when you have more than 2 Values, it is quiet more useful when you have names to access them, because my own experience shows that this can truely leed to buggy code easily^^, when you made a mistake with the itemX…
Prety much. Except you’re mixing up integers and chars there.
These both work:
var myStackAllocatedArray: array[0..6] of Integer := [0, 1, 2, 3, 4, 5, 6];
var span: Span<Integer> := new Span<Integer>(@myStackAllocatedArray[2], 3); // starts at 2
var span2: Span<Integer> := new Span<Integer>(myStackAllocatedArray, 3); // << starts at 0