There is one issue regarding user-defined types: #41, however, our idea of how the user-defined types should look changed quite a bit. I will summarize here what we came up with and what we are missing.
This issue will be updated with new ideas, things we still need to figure out...
Syntax
State
We would have two types of classes:
Braced classes
Paren classes
Braced classes
For non-POCO usecases (actual OO design)
No constructor provided implicitly
Expected to write factory functions
Initialization through the initializer syntax
Only state is described here, meaning auto-props and fields
class Foo {
// Gettable and settable auto-prop
public var X: int32;
// Get-only auto-prop
public val Y: string;
// Mutable field
internal field var Z: int32;
// Readonly field
public field val W: string;
}
Paren-classes
Essentially named tuples, mainly targeting POCOs (exposed data-structures, utility-types)
Order of the state is exposed
Primary ctor that can be used for initialization
Only state is described here, meaning auto-props and fields
class Bar(
// Gettable and settable auto-prop
public var X: int32,
// Get-only auto-prop
public val Y: string,
// Mutable field
internal field var Z: int32,
// Readonly field
public field val W: string);
Logic
Any associated behavior of the type is described within a logic block. The logic block can be thought of associating members with a type (not necessarily an instance of the type). Multiple logic blocks can be specified for a type, essentially making this very similar to extension methods.
logic Foo {
// 'This' keyword is an implicit alias to Foo
// Static factory
public func make(): This = This { ... };
// Member method
public func toString(this): string = ...;
// Associated value, AKA. static field, property, ...
private field var instanceCount: int32;
}
// Implementing a trait, interface or base class
logic IComparable<Bar> for Bar {
// Only members are allowed here that are present in IComparable<Bar>
}
Member functions
Non-static functions take this parameter while static does not, otherwise, they look the same as free functions.
Properties
Non-static properties take this parameter while static do not.
Properties allow for declaring backing fields inside their scope, which means the backing fields are not visible anywhere outside the prop.
The set accessor has implicit value parameter.
prop Foo(this): int32{
var backingField = ...;
get { ... }
set = ...;
}
// computed props
prop Bar(this): int32 = ...;
There is one issue regarding user-defined types: #41, however, our idea of how the user-defined types should look changed quite a bit. I will summarize here what we came up with and what we are missing.
State
We would have two types of classes:
Braced classes
For non-POCO usecases (actual OO design)
Only state is described here, meaning auto-props and fields
Paren-classes
Essentially named tuples, mainly targeting POCOs (exposed data-structures, utility-types)
Logic
Any associated behavior of the type is described within a
logic
block. Thelogic
block can be thought of associating members with a type (not necessarily an instance of the type). Multiple logic blocks can be specified for a type, essentially making this very similar to extension methods.Member functions
Non-static functions take
this
parameter while static does not, otherwise, they look the same as free functions.Properties
Non-static properties take
this
parameter while static do not. Properties allow for declaring backing fields inside their scope, which means the backing fields are not visible anywhere outside the prop. Theset
accessor has implicitvalue
parameter.