4 ms·

Looks really nice! Some questions: - What does a non-null reference compile to? An array parameter with at least 1 object ([static 1])? - Will fin support Var

Looks really nice! Some questions: - What does a non-null reference compile to? An array parameter with at least 1 object ([static 1])? - Will fin support Variably Modified Types? - Does fin understand _Generic and static_assert (extremely useful for compile time proofs) from C11 and later? - Are there any plans for compile time execution (like constexpr/constinit/consteval from C++)? - What about integer promotion rules? - Do unions work like in C? They are useful for type punning and serialization Edit: formatting

adamfk 3y ago
Great questions! Much appreciated :) > What does a non-null reference compile to? A non-null fin reference will transpile to a C99 pointer. The non-null aspect is for fin code. > Will fin support Variably Modified Types? Yep. Assuming you mean something like this: ```c int someArraySize; int myArray[someArraySize]; ``` > Does fin understand _Generic and static_assert, or constexpr? I definitely want to support static_assert. constexpr like functionality will eventually be supported. I had forgotten about _Generic! Do you actually use it in production code? I've never really seen it in the wild outside of experiments. > What about integer promotion rules? Great question. I'll be following how C# does it for the most part. Specifically when comparing a int and uint, both will be first promoted to the next largest type automatically instead of int being treated as unsigned which is a common mistake. > Do unions work like in C? They are useful for type punning and serialization Really great question! We can support them, but I'd like to provide better portable serialization. Something like ```cs bool success = SomeFinLib.try_deserialize(to: packet, from: bytes); ```
- sigsev_251 3y ago
  > A non-null fin reference will transpile to a C99 pointer. The non-null aspect is for fin code. Why not use the foo[static 1] trick, it's literally a standard non null pointer (and many C compilers issue diagnostics when someone tries to pass null)? > Yep. Assuming you mean something like this: > >```c int someArraySize; int myArray[someArraySize]; ``` Yes, this covers my question. Basically, guidelines like CERT require the use of them in function signatures (unless someone uses MSVC) to clarify intent. Also it helps static analyzers detect erroneous buffer management. > I definitely want to support static_assert. constexpr like functionality will eventually be supported. Awesome! > I had forgotten about _Generic! Do you actually use it in production code? I've never really seen it in the wild outside of experiments. Yes, it is used in professional code, though not for function overloading most of the times. Basically it can be used to implement type traits similar to those in C++, detect if an integer type will promote to int (especially useful for uint16_t), create compile time if, implement a type safe lengthof macro, etc. All in all it's a tool that helps with type safety. I'm pretty sure that it's used in the Linux kernel these days. > Great question. I'll be following how C# does it for the most part. Specifically when comparing a int and uint, both will be first promoted to the next largest type automatically instead of int being treated as unsigned which is a common mistake. Ok, that makes sense > Really great question! We can support them, but I'd like to provide better portable serialization. Something like Many times I have wondered why serialization is not supported as a first class citizen in low level languages, especially when it's something that is done all the time in embedded. Though be aware, unions for other uses of type punning, like accessing the storage of a float as a uint32_t (after asserting that they are of the same size of course) to work with the format itself. This is useful for some numerical algorithms, like scaling.
  - adamfk 3y ago
    Wow!!! Thanks for showing me the `foo[static 1]` trick. I had never seen it before. Really cool! I added https://github.com/fin-language/fin/issues/6 https://github.com/fin-language/fin/issues/6 to track. Also good point on accessing float storage for numerical algorithms. Hadn't considered that. Hmm... that code will not be portable. It might make the most sense for it to live in regular C code. Fin generated C code can call hand written C and vice versa. If you have time/interest, I think the fin project could benefit a lot from your suggestions and guidance.

adamfk 3y ago

Great questions! Much appreciated :) > What does a non-null reference compile to? A non-null fin reference will transpile to a C99 pointer. The non-null aspect is for fin code. > Will fin support Variably Modified Types? Yep. Assuming you mean something like this: ```c int someArraySize; int myArray[someArraySize]; ``` > Does fin understand _Generic and static_assert, or constexpr? I definitely want to support static_assert. constexpr like functionality will eventually be supported. I had forgotten about _Generic! Do you actually use it in production code? I've never really seen it in the wild outside of experiments. > What about integer promotion rules? Great question. I'll be following how C# does it for the most part. Specifically when comparing a int and uint, both will be first promoted to the next largest type automatically instead of int being treated as unsigned which is a common mistake. > Do unions work like in C? They are useful for type punning and serialization Really great question! We can support them, but I'd like to provide better portable serialization. Something like ```cs bool success = SomeFinLib.try_deserialize(to: packet, from: bytes); ```

sigsev_251 3y ago
> A non-null fin reference will transpile to a C99 pointer. The non-null aspect is for fin code. Why not use the foo[static 1] trick, it's literally a standard non null pointer (and many C compilers issue diagnostics when someone tries to pass null)? > Yep. Assuming you mean something like this: > >```c int someArraySize; int myArray[someArraySize]; ``` Yes, this covers my question. Basically, guidelines like CERT require the use of them in function signatures (unless someone uses MSVC) to clarify intent. Also it helps static analyzers detect erroneous buffer management. > I definitely want to support static_assert. constexpr like functionality will eventually be supported. Awesome! > I had forgotten about _Generic! Do you actually use it in production code? I've never really seen it in the wild outside of experiments. Yes, it is used in professional code, though not for function overloading most of the times. Basically it can be used to implement type traits similar to those in C++, detect if an integer type will promote to int (especially useful for uint16_t), create compile time if, implement a type safe lengthof macro, etc. All in all it's a tool that helps with type safety. I'm pretty sure that it's used in the Linux kernel these days. > Great question. I'll be following how C# does it for the most part. Specifically when comparing a int and uint, both will be first promoted to the next largest type automatically instead of int being treated as unsigned which is a common mistake. Ok, that makes sense > Really great question! We can support them, but I'd like to provide better portable serialization. Something like Many times I have wondered why serialization is not supported as a first class citizen in low level languages, especially when it's something that is done all the time in embedded. Though be aware, unions for other uses of type punning, like accessing the storage of a float as a uint32_t (after asserting that they are of the same size of course) to work with the format itself. This is useful for some numerical algorithms, like scaling.
- adamfk 3y ago
  Wow!!! Thanks for showing me the `foo[static 1]` trick. I had never seen it before. Really cool! I added https://github.com/fin-language/fin/issues/6 https://github.com/fin-language/fin/issues/6 to track. Also good point on accessing float storage for numerical algorithms. Hadn't considered that. Hmm... that code will not be portable. It might make the most sense for it to live in regular C code. Fin generated C code can call hand written C and vice versa. If you have time/interest, I think the fin project could benefit a lot from your suggestions and guidance.