`with` clauses

[SkiFire13]

@tema2

"expl. introduction, implicit propagation, explicit requirements, explicit use".

This is misleading, you can't have implicit propagation and explicit requirements at the same time. What you actually have is just implicit requirements and sometimes explicit ones. This is big no-no for me because it means potential for hidden breaking changes and headaches.

Immagine a situation like this:

• You're making a library with:

fn foo() with (&mut Context) {}
fn bar() { foo() }
pub fn baz() {}

• baz wasn't calling anything that required a context and was ok;
• you change baz to call bar without using a with clause;

fn foo() with (&mut Context) {}
fn bar() { foo() }
pub fn baz() { bar()}

• the library compiles, because baz gets a new implicit requirement;
• you, as the library author, don't notice the breaking change because your function signature didn't change and your library compiled;
• some user of your library was calling baz from main without provind a context. It worked, but with your new change it doesn't work anymore. You've just made an hidden breaking change.

This doesn't look pain free to me.

[tema2]

@SkiFire13

What you actually have is just implicit requirements and sometimes explicit ones.

Yea, this is better formulation.

@SkiFire13

some user of your library was calling baz from main without provind a context. It worked, but with your new change it doesn't work anymore. You've just made an hidden breaking change.

Obvious way to mitigate this is to force pub items to declare with bounds, if needed, and make them not do implicit requirements of with env. .

So that in your example pub fn baz() will raise an error like "error: no with ctx. is provided: please provide one: with (...) {...} or pub fn baz() with (...) note: pub items don't recieve implicit with bounds"

[H2CO3]

@tema2

Obvious way to mitigate this is to force pub items to declare with bounds

Now we are talking about items changing behavior based on visibility scope? No, absolutely not, don't do this, please just stop.

[robinm]

It’s not behavior, it’s capabilities. That’s not at all the same thing.

[H2CO3]

I don't particularly care what it's called, I'm not trying to argue the semantics of words. My concrete problem is that having implicit bounds on private items is bad because it's surprising, and having implicit bounds on private items while also requiring them explicitly on public items is even worse, because it's partly surprising, and partly painful.

[tema2]

@H2CO3

having implicit bounds on private items while also requiring them explicitly on public items is even worse, because it's partly surprising, and partly painful.

I have to note that having implicit bounds on private items is here only to avoid requiring to put explicit ones everywhere (this problem is not specific to this mechanism, but is of effects of any kind in general). Also, I don't think it's too suprising, esp. if person is familiar with the concept. Ofcourse, there are possibilities to misuse these capabilities, as with all implicit construct, but this is the price for needed convenience.

[tmandry]

Someone pointed me to this thread and while I haven't caught up with it yet, I posted an updated version of the original proposal on my blog. (comment thread)