[rust-dev] std::num::pow() is inadequate / language concepts
std::num::pow is not the most general exponentiation function but a second-rate utility function in the standard library - you don't have to use it. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] std::num::pow() is inadequate / language concepts
[The previous message got sent accidentally by gmail]
However, for performance reasons, I think some kind of trait overloading
would be nice.
i.e., you should be able to do
implT TraitT for Aφ { ... }
overload impl Traitint for Aφ[int/T] {
//...
}
And when using (x : Traitint) the items in the overload impl will be used
instead of the items in the base impl (note that, except for associated
types, overloaded traits won't participate in name resolution/type checking
- so probably force associated types in the overload to be the same as the
base).
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] RFC: Struct Self-Burrows
Hi,
Currently, Rust has C#-like implicit variance - actually it's even more
implicit then C#, being inferred automatically - which is nice in being
boilerplate-light.
However, in some cases more explicit variance would be desired, as in this
example:
Say Library A has a mutable AContext, and Library B, which depends on
Library A, has a BContext which depends on the AContext.
We could type this as follows:
struct AContext {
priv state: RefCellAInternalState,
...
}
fn create_acontext() - AContext;
struct BContext'a {
acontext: 'a AContext,
...
}
fn create_bcontext'a('a AContext) - BContext'a;
And use it like:
let acontext = create_acontext()
let bcontext = create_bcontext_(acontext)
(Note that acontext: ~AContext won't work, because Library B objects may
have a reference to a subobject of the AContext, and besides, the user may
like to use the AContext themselves)
However, this forces the user of Library B to interact with its
dependencies, and if Library B depends on half a dozen other libraries and
the user creates ten contexts in his tests, we have a problem.
We would like to create a function that creates a BContext and an AContext
together - however, someone needs to manage the ownership of the AContext
and make sure it goes with the BContext.
A potential solution is to use RcAContext, but this creates Rc pollution
when the lifetime is static - now objects with a pointer to part of
AInternalState need to use an Rc.
Note that the lifetime of the inner AContext is completely static here - it
goes with the BContext. We could have something like this:
struct BContextHolder {
priv acontext: ~AContext,
ctx: BContext'something
}
fn create_bcontext() - BContextHolder {
let actx = ~create_acontext()
BContextHolder {acontext: actx, ctx: create_bcontext_(actx))
}
However, this isn't legal rust - we can't find a good lifetime for
'something - and besides, acontext isn't burrowed so people can free it.
I think I found a way to solve this - allow struct fields to have burrows
into *other fields of the same struct*:
A (bad) syntax for this is
struct BContextHolder {
priv 'a acontext: ~AContext,
ctx: BContext'a
}
Which means that the field acontext is borrowed in the lifetime 'a, which
is also the lifetime of ctx.
I didn't formalise this, but from where I looked we essentially need to:
1) Make sure that people accessing acontext see it as burrowed
2) Make sure you can't just change acontext
3) Make sure the burrow relationships are not strengthened when
structuring/destructuring.
This post is getting tl;dr already so I'll end it here.
--
Ariel Ben-Yehuda
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] RFC: Struct Self-Borrows
[/Burrow/Borrow/ damn spellcheck]
More thoughts on this:
The syntax I used earlier ('a NAME) has a potential problem that it would
make the pointer borrowed, rather then the pointee. I don't really
understand the rules of borrowed owned ptrs: can you write through them?
can others have live aliases? (If unique ptrs work internally like Rcs
then that' parts fine [~T - 'a ~T - 'a T], the latter by an automatic
.borrow()) -- but I'm not really interested in declaration syntax here.
By the way, are ~ptrs special to the borrow checker in any way other then
autoref/deref (By the looks of it DST will make slices not special to the
borrow checker and special @s were turned into non-special Rc's -- is the
same thing being done for ~s)?
Informal semantics:
structs can have fields borrowed to a lifetime. That binds the lifetime
(if you use the same name twice you get an error).
If a field is borrowed to a lifetime:
a) When constructing the struct, a borrowed value can be used as long as
you put all references into the right places in the new struct
b) Dually, when destructing the struct, the parts end up borrowed in the
same relationship they were in the struct.
c) It can only be accessed borrowed to that lifetime.
d) It can't be set
The latter 2 behave in the same way as a borrowed unique pointer in a stack
frame -- you can say that this proposal makes stack frames less special by
allowing ordinary structs to root borrows. This has the disadvantage of
making lifetimes non-totally-ordered. Is that too bad?
--
Ariel Ben-Yehuda
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] RFC: Struct Self-Burrows
Hi,
Currently, Rust has C#-like implicit variance - actually it's even more
implicit then C#, being inferred automatically - which is nice in being
boilerplate-light.
However, in some cases more explicit variance would be desired, as in this
example:
Say Library A has a mutable AContext, and Library B, which depends on
Library A, has a BContext which depends on the AContext.
We could type this as follows:
struct AContext {
priv state: RefCellAInternalState,
...
}
fn create_acontext() - AContext;
struct BContext'a {
acontext: 'a AContext,
...
}
fn create_bcontext'a('a AContext) - BContext'a;
And use it like:
let acontext = create_acontext()
let bcontext = create_bcontext_(acontext)
(Note that acontext: ~AContext won't work, because Library B objects may
have a reference to a subobject of the AContext, and besides, the user may
like to use the AContext themselves)
However, this forces the user of Library B to interact with its
dependencies, and if Library B depends on half a dozen other libraries and
the user creates ten contexts in his tests, we have a problem.
We would like to create a function that creates a BContext and an AContext
together - however, someone needs to manage the ownership of the AContext
and make sure it goes with the BContext.
A potential solution is to use RcAContext, but this creates Rc pollution
when the lifetime is static - now objects with a pointer to part of
AInternalState need to use an Rc.
Note that the lifetime of the inner AContext is completely static here - it
goes with the BContext. We could have something like this:
struct BContextHolder {
priv acontext: ~AContext,
ctx: BContext'something
}
fn create_bcontext() - BContextHolder {
let actx = ~create_acontext()
BContextHolder {acontext: actx, ctx: create_bcontext_(actx))
}
However, this isn't legal rust - we can't find a good lifetime for
'something - and besides, acontext isn't burrowed so people can free it.
I think I found a way to solve this - allow struct fields to have burrows
into *other fields of the same struct*:
A (bad) syntax for this is
struct BContextHolder {
priv 'a acontext: ~AContext,
ctx: BContext'a
}
Which means that the field acontext is borrowed in the lifetime 'a, which
is also the lifetime of ctx.
I didn't formalise this, but from where I looked we essentially need to:
1) Make sure that people accessing acontext see it as burrowed
2) Make sure you can't just change acontext
3) Make sure the burrow relationships are not strengthened when
structuring/destructuring.
This post is getting tl;dr already so I'll end it here.
--
Ariel Ben-Yehuda
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
