Open KoziLord opened 3 years ago
Re 9. Have you heard of expression-only? (F#)
For no. 9 Rust does it right IMO. It has almost everything as an expression.
This just sounds like rust
About expression blocks, I actually dislike how Rust makes the last expression the value of the block. I think it is too hidden. My Azoth, I use the =>
operator as providing a value for the surrounding block. You can also use it in place of an operator. So the example given could become:
bool someCondition = {
i32 responseCode = inScopeLocal.DoSomething();
=> if (responseCode != 0) => true;
else
{
Log("Operation failed");
=> false;
};
};
These are some of my ideas for a language with emphasis on direct control and low-level control while also offering a lot of expressiveness. All the ideas were conceptualised with a native language in mind but I'm posting here by @LPeter1997's request.
1. No reference types All data types are value types, to pass something by reference one must take a pointer to a value type.
2. Safe pointers Pointer arithmetic is illegal outside of
unsafe
blocks, pointers are also split into two categories: Nullable pointers and non-nullable pointers. (What would be the syntax to distinguish them?)3. No visibility modifiers on fields For abstraction, you'd write against traits instead of concrete data types, as soon as you want complete control over everything you can use the concrete type and access all its data.
4. Immutable by default Immutability is handy but you can't expect people to tag things as immutable, making it the default avoids this problem and instead forces people to tag things as mutable when they really need mutability.
5. Traits and generics All types can be extended from anywhere, allowing you to write generic code against traits then adding support for those traits to types you care about. Variadic generics included, with the ability to index them, avoiding the C++ recursive mess.
6. Compile-time reflection and code-gen capability Just steal JAI's fancy compile-time functionality. That's pretty much it.
7. Iterator APIs, similar to functional languages/LINQ They're too handy not to have them, especially if you can afford to transform them into code similar to what a for loop would produce. Also includes the good old
for (T x in Y)
loop.8. Discriminated unions and pattern matching Pattern matching (switch expressions) would work against anything implementing a matching trait with the standard library providing a type implementing it.
9. Expression blocks Allow wrapping blocks of code in an expression block, reducing the need for separate one-of-a-kind functions and ternaries where they're not actually needed.
An imaginary example of how such a block could look like:
(I can't come up with a better example, will replace it with one if I find it)
I'm probably gonna be adding more to this list and I'll be making a list of issues that will need figuring out.