`with` clauses

language design
21

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.

7 Likes
22

Yea, this is better formulation.

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"

2 Likes
23

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

2 Likes
24

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

3 Likes
25

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.

5 Likes
26

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.

2 Likes
27

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)

1 Like
28

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.