Hacker News Reader

Comment by vilya | Hacker News Reader

This looks like a bad design. It means either (a) the semantics of 'ret' inside a lambda function can change depending on the call site (whether it's used inside a for loop or not); (b) that a lambda function passed in from elsewhere can cause your function to return early; or (c) that lambda functions have different syntax rules depending on where they're being defined. All of which seem equally bad!

I hope there's something I've missed. I've been quite impressed by the rest of the language so far & it would be a shame if they got this wrong.

View on HN

You're missing something. The semantics of `ret` are always consistent: it always returns from out the innermost `fn()` declaration (closures written using the sugared notation `{||...}` do not count as fn declarations, but closures written as `fn() { ... }` do). In cases where this is not possible, a static error is generated.

So what happens if we pass a stack closure containing a ret into another function? For example, what would this code print out:

  fn foo(f: fn()) {
    log(info, "calling f");
    f();
    log(info, "called f");
  }

  fn bar() {
    log(info, "calling foo");
    foo({||
      ret;
    });
    log(info, "called foo");
  }

I'm not clear on whether the ret would return from foo or from bar - or whether it would be a compile error.

BTW thanks for taking the time to reply - I appreciate it!

Tried compiling this myself with a main function that just calls bar(), resulting in a compiler error:

  `ret` in block function

I feel continually obligated to remind people that if there's some aspect of the language that they don't like, they should speak up! :) The devs are always looking for feedback, either on the mailing list, the Github issue tracker, or in #rust on irc.mozilla.org.

That said, perhaps there is something you've missed. I've posted links to the Rust mailing list elsewhere in this thread, could you skim over those and let me know if they address your concerns? Honestly I'm not super-thrilled at this change myself, if only because it makes for loop invocations a bit busier to look at, but I can't say that I fully understand the semantic tradeoffs here.

I wrote up a quick blog post to spell out some of the examples and show how the design aims for a consistent meaning for the `ret` keyword:

http://smallcultfollowing.com/babysteps/blog/2012/04/06/for-...

Reply on news.ycombinator.com