RFC: type vs alias
type and alias both create a new type identifier in the unit scope, however type creates a new type whereas alias creates a new name for an existing type.
type [u8] as str8
type creates a 'copy' of an existing type and gives it a new name. New traits can be applied to new type definitions without affecting the original type.
As seen above, this is the critical element used by the str8 type - a UTF-8 string. str now inherits the array property .length, and now allows more traits and methods to be applied to it without those types being applied to the [u8] type itself.
Remember that array types are their own type -
[u8]is not the same type asu8(see #12)
alias str8 as str
alias gives a new name to an existing type without creating a new type altogether. All applications of traits on str will affect str8.
The above example is what creates the built in str type - str is really just str8.
Here is a truth table for type vs alias:
T as U |
type |
alias |
|---|---|---|
| T is U | False | True |
| U assignable to T | True | True |
| (U.foo = fn()) == T.foo | False | True |
I think if you're wanting a more C/C++ feel to the language, I think staying with alias or the more Swift-esque syntax typealias should be used.
As for using the alias <type> as <alias name>, for me anyway typing any more words than needed to me seems a waste of your file cough Visual Basic cough. So if I was doing this I'd do what C/C++ does!
typedef old_type newType;
But yours could be:
alias [i8] Integer8Array
Good point about Visual Basic. However, when thinking about typedef readability in C++, these kinds of typedefs come to mind:
typedef __detail::_Adaptor<_Engine, _Dist> engine_value_type;
typedef __detail::_Hash_node<_Value, __cache_hash_code> _Node;
typedef integral_constant<bool, __stored_locally> _Local_storage;
Obviously some of the above are due to underscores in identifiers, which (as of now) Arua will not allow. The underscores are used as internal identifiers, which should be properly zoned away as to not allow public access anyway.
So as an experiment, let's remove the underscores and use as, use . instead of ::, and properly capitalize things:
alias Detail.Adaptor<Engine, Dist> as EngineValueType
alias Detail.HashNode<Value, CacheHashCode> as Node
alias IntegralConstant<bool, StoredLocally> as LocalStorage
and without as:
alias Detail.Adaptor<Engine, Dist> EngineValueType
alias Detail.HashNode<Value, CacheHashCode> Node
alias IntegralConstant<bool, StoredLocally> LocalStorage
The common theme with as is that it performs a conversion operation, including pattern matching. This would be no exception - that's the intent of the word as.
In my personal opinion, the former example is more readable than the latter. With readability in mind, I think it's a fair tradeoff.
Ah okay, well if you're going for a more convertible language this would be the most viable option. As for pattern matching this would most likely be faster for this language, that is true.
P.S, in that example of using alias with "as", I notice the CPP template syntax. Will Aura have templates? Obviously I understand it would be in a later update but, is it a possibility?
@Polyg0n I'm pretty sure I want them. I want to make sure they mesh well with the trait-based design. If they are incorporated, they will semantically resemble Java's generics more than C++'s templates, but I'm sure underlying implementation will be more similar to templates than generics. I haven't given them a ton of thought yet.
Per-type generics are almost strictly an inheritance thing. I could easily see per-function generics, though.
@Qix-, honestly per function generics would be beautiful. I've used C++ templates and Java generics both of which are powerful and great. But per-function generics would be awesome.
The top-most post has been updated to reflect the current state of the RFC.
typedef -> type. Seems much cleaner and drives home that it's an actual new type (unlike C++ treating it more like an alias).
@Qix- So you're going for more a TypeScript style of type aliasing?[ as far as syntax goes ] but you're creating an new physical type [ as far as what the compiler sees ] TypeScript -
type someType = string
Possible Arua implementation -
type someType as u32
Precisely, though backwards. as' pattern of thought is something should be known as....