Remove default bounds on ~ objects and procs

[nikomatsakis]

Today we do some amount of defaulting to cover two special cases:

~Trait =>  ~Trait:Send
proc   =>  proc:Send

This means that you must write ~Trait: and proc: to bypass these defaults.

I think we should consider removing these defaults and be consistent: no bounds means no bounds.

Arguments in favor of defaults:

• Less typing for the common case of sendable ~Trait objects and proc

Arguments against:

• We don't generally default other places in the language

• proc:Send and ~Trait:Send read quite clearly to me

• The fact that proc: is even an option is not obvious, leading people to the false conclusion that one cannot e.g. close over borrowed values in a proc

• There are other use cases for ~Trait and proc that don't involve sending

• Defaults are somewhat confusing in the face of DST. Consider these types:

  struct Foo<A> { x: ~A }
  struct Bar<A> { x: A }
  

  Wouldn't you think that Foo<Trait> and Bar<~Trait> should be equivalent?
  I would, but they're not.

[orenbenkiki]

First, +1. I find the current state pretty confusing, perhaps because proc isn't mentioned in the documentation at all. The following fails to compile (obviously):

fn call_once(action: proc() -> T) -> T {
    action()
}

fn consume_owned(_text: ~str) {}
fn used_borrowed(_text: &int) {}

fn lets_try(foo: &int, bar: ~str, baz: &mut_int) {
    mut int qux = 0;
    do call_once {
        used_borrowed(foo);
        consume_owned(bar);
        *baz += 1;
        qux += 1;
    }
}

I'm not sure what you mean by proc: - putting proc: instead of proc in the above doesn't compile. So how is it possible (today) to make the above work?

[pnkfelix]

cc me

[emberian]

👍. I had no idea default bounds were a thing, or that ~SomeTrait: was valid syntax.

[alexcrichton]

@pcwalton ran into something a little related yesterday. All of the runtime's I/O structures are wrappers around some ~Trait object. The idea of these is that they're all sendable across tasks (one can read while the other writes, etc). Specifically, though, the Freeze bound couldn't get inferred for those objects, and having to specify the Send bound everywhere would be a bit of a pain (although entirely plausible).

This may just be a reflection of the runtime's decision to use trait objects instead of generics, but it would make some use cases a little harder. That being said, I'd almost want to lean on the side of consistence and not have any funny bounds inferred for you when you didn't want them.

[nikomatsakis]

@alexcrichton yes, some cases get more verbose. Are these many different traits or a single trait? In the latter case, you can certainly make a typedef as well:

trait Callback
type CB = ~Callback:Send;

[alexcrichton]

Sadly there's a fair number of traits (all in std::rt::rtio), but I also just found out that you can do trait Foo: Send {}, so I don't think that this would be that bad at all (I'm in favor of removing the defaults).

[nikomatsakis]

@alexcrichton I was about to suggest that (moving the bound to the trait itself)

[alexcrichton]

We discussed this in today's meeting, and we decided that these default bounds should go.

[nikomatsakis]

In #10553 it was pointed out that a Send bound should imply 'static, just something to keep in mind when implementing this.

[wycats]

Incidentally, this issue caused me a bunch of pain when I was trying to implement a generic trait over objects that contained references (In my case, Matcher<T>).

The error message didn't really explain what I was doing wrong, and there wasn't an easy way to opt out of the Send bound (even Matcher:<T> didn't seem to be possible in all the places I needed to reference the trait and opt-out). It's possible I missed something (an easy opt-out), but the current situation is pretty brittle and the error messages don't send you down the right path.

In any event, I agree that Send should not be the default here.