[FEATURE REQUEST/Bug] Vector::<T> lets you use items with lifetimes. Syntax is necessary to annotate the a type paremeter's lifetime should be applied #19
Description of the feature
Vector::<&i32> is technically valid. This is fine if it remains in local scopes. BUT it uses UntypedPointer.... which is not lifetime checked. This also applies to Box::<T>. There needs to be a way to annotate that T (or any other type parameter) should carry it's lifetime to type who's type parameters are being resolved.
Examples of usage
struct Vector::<`T> {
// None of these members affect the lifetime constraints of Vector::<T>
refc_ptr: UntypedPointer,
data_ptr: UntypedPointer,
size_ptr: UntypedPointer,
real_size_ptr: UntypedPointer;
}
define some_func() -> Vector::<&i32> {
my_vec = Vector::<&i32>();
my_vec.append(&69);
return my_vec; // Should throw an error
}
struct Box::<`T> {
// None of these members affect the lifetime constraints of Box::<T>
refc_ptr: UntypedPointer,
data_ptr: UntypedPointer;
}
define some_func() -> Box::<&i32> {
my_box = Box::<&i32>::wrap(&69);
return my_box; // Should throw an error
}
Syntax info
struct MyStruct::<~T> // T requires a long lived life and carries it's lifetime to MyStruct
struct MyStruct::<`T> // T carries its lifetime to MyStruct
struct MyStruct::<`T, `E> // T & E carries their lifetimes to MyStruct. The smallest of the lifetimes is used.
struct MyStruct::<~T, ~E> // T & E require a long lived life and carries their lifetime to MyStruct. The smallest of the lifetimes is used.
struct MyStruct::<~T, `E> // T require a long lived life. T & E carries their lifetime to MyStruct. The smallest of the lifetimes is used.
Possible issues that may make this feature difficult to implement
Nothing about this is particularly difficult. If you want T to automatically get a decided lifetime, then that is a lot harder, but not impossible.
The hardest part is the cases with multiple type parameters with lifetime annotations.
Additional context
This kind of goes against some of the simpler nature of the automatic lifetime detection model. The entire point is to avoid annotations like this. The good thing is that they are only required in special, unsafe cases like this. But, that does mean it makes it harder to understand and read the code in the standard library.
ArachnidAbby
commented
11 months ago
Description of the feature Vector::<&i32> is technically valid. This is fine if it remains in local scopes. BUT it uses UntypedPointer.... which is not lifetime checked. This also applies to
Box::<T>. There needs to be a way to annotate thatT(or any other type parameter) should carry it's lifetime to type who's type parameters are being resolved.Examples of usage
Syntax info
Possible issues that may make this feature difficult to implement Nothing about this is particularly difficult. If you want T to automatically get a decided lifetime, then that is a lot harder, but not impossible.
The hardest part is the cases with multiple type parameters with lifetime annotations.
Additional context This kind of goes against some of the simpler nature of the automatic lifetime detection model. The entire point is to avoid annotations like this. The good thing is that they are only required in special, unsafe cases like this. But, that does mean it makes it harder to understand and read the code in the standard library.