#rust-lang

wrt. auto-deref when Copy, wouldn't that mean code might stop working when one adds Copy to a type?

phaylon: it would only mean that code starts compiling that didn't already

afaict

even when the type of `foo.bar` would change from &X to X?

phaylon: I mean, I imagine that it would only autoderef if necessary

e.g. foo<T:RefOrOwned>(_: T) {} foo(bar.baz) and flip copy-ness of .baz

as in "if it doesn't work, try compiling the other way"?

phaylon, it woudln't *change* from &X to X, it would be &X unless you tried to unify it with X

so if the code compiled with the value as &X nothing would change

so yes, what ubsan said

ah

would the visible semantics for non-copy types be similar like the pass-owned-to-ref proposal, as in it auto-refs but consumes the field/object?

phaylon, I don't know what you mean

there's a proposal floating around allowing `fn foo(t: &T) {} foo(owned_t)` that's basically `{ foo(&owned_t) }`, so it auto-refs, but acts like it was moved

so I was wondering if `foo(something.owned_t)` would follow those semantics

just thinking out loud at this point, I'm more of a be-explicit kinda guy

phaylon, i think there's not a connection.

this is about where `something` is `&T`, you get a reference from `something.owned_t`

you're talking about if `something` is `T` but the foo takes a reference

ah, true

so yea it would work the same way for `t` or `x.t` but that's just because they're both expressions that evaluate to `T`

also I am so close to that sweet nagbot 0

I'm not understanding that last line :) I assume I'm missing context

phaylon, there's a bot that emails team members about RFCs and issues they need to comment on, my daily email only had 1 item today

aah, there's the context

for a moment I thought I was the nagbot. I'm sometimes worries that I'm criticising too much

phaylon, not at all :)

https://is.gd/LHX7ed The new frontiers of typenum, it'll be fairly trivial to implement `where {x < y}` type of clauses with const generics

eddyb, did you know this?

lol

people will definitely do this

woboats: this is Refl isn't it

I'm not sure.. they at least have to be compile time values still

like you can just do where (): IsTrue<{f(X)}>

yes exactly

gee

so you dont even need custom traits

or bool: Is<{f(X)}, true> if we allowed const LHS: Self

rewritten https://is.gd/bhsxvW

woboats: do note that unification is used to compare these

so you can't repeat a bound to make a "perfect proxy" *unless* two distinct {f(X)} expressions unify with eachother without a known X

so I'm sure people doing this will immediately want us to implement a smarter theory of equality

woboats: which is what we need for bool constant predicates in where clauses or whatever

I don't like boolean predicates because I'm afraid of the programs people will write with them

in terms of having comprehensible APIs

like, that smarter equality we won't have from the start is why we don't have bounds from the start, in terms of technical reasons

that makes sense

hmmm i guess i thought of these questions as very distant but it seems like they'll be raised quickly after const generics are implemented

hmmmmm

woboats: ooh

what your trait scheme allows you to do

is proxy a bound

because you have no expressions in the bound itself

i.e. two LessThan<X, Y> or w/e unify with eachother

in a way expressions don't

or rather, you're emulating the fancier expression equality by "desugaring" it into constructs rustc already understands well

right

so the only thing is it can't prove things like

GreaterThan<X, Y> implies LessThan<Y, X>

well maybe it can but i dont think so?

Is it possible to make a sanitizer for the property TBAA relies on?

Hi

idea

DerefAssign could allow us to make `*v = [1, 2, 3]` work really nicely

(plus rvalue dsts)

ubsan: DerefAssign is what I thought <- could be :P

eddyb: no

obviously not

<- is for placement

i.e., no dropping!

(I mean, (*v.back() = value): &mut T instead of (v.back() <- value): &mut T)

ah that makes sense somewhat