Skip to content
This repository has been archived by the owner on May 11, 2019. It is now read-only.

RFC: type vs alias #3

Open
Qix- opened this issue Nov 8, 2015 · 9 comments
Open

RFC: type vs alias #3

Qix- opened this issue Nov 8, 2015 · 9 comments

Comments

@Qix-
Copy link
Owner

Qix- commented Nov 8, 2015

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 as u8 (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
@corbin-r
Copy link

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

@Qix-
Copy link
Owner Author

Qix- commented Nov 24, 2015

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.

@corbin-r
Copy link

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?

@Qix-
Copy link
Owner Author

Qix- commented Nov 24, 2015

@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.

@corbin-r
Copy link

@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.

@Qix- Qix- mentioned this issue Nov 24, 2015
@Qix-
Copy link
Owner Author

Qix- commented May 31, 2016

The top-most post has been updated to reflect the current state of the RFC.

This was referenced May 31, 2016
@Qix- Qix- changed the title RFC: typedef vs alias RFC: type vs alias Sep 6, 2016
@Qix-
Copy link
Owner Author

Qix- commented Sep 6, 2016

typedef -> type. Seems much cleaner and drives home that it's an actual new type (unlike C++ treating it more like an alias).

@corbin-r
Copy link

corbin-r commented Sep 6, 2016

@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

@Qix-
Copy link
Owner Author

Qix- commented Sep 6, 2016

Precisely, though backwards. as' pattern of thought is something should be known as....

@Qix- Qix- added rejected and removed confirmed labels Feb 5, 2017
@Qix- Qix- removed this from Accepted in RFCs Feb 5, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants