Things Rust shipped without • Hacker News Board

Re: Things Rust shipped without

#111

Post by arcticbull » Fri, Jul 03, 2015, 9:43 PM UTC

zem wrote: post #90

frivoal wrote: post #68

Earlier quoted context omitted.

A bitecode interpreter is another place where it's nice to have gotos. Here's the base code without gotos: typedef enum { ADD, MUL, ..., END } opcode; void run() { opcode ins; while (1) { ins = fetch_next_inst(); switch (ins) { case ADD: perform_addition(); break; case MUL: perform_multiplication(); break; ... case END: wrap_up(); return; } } } You have 3 jumps on each loop. From the break to the end of the loop, the…

~20 years of using various combinations of C and C++, and i never knew you could take the address of a label! reminds me of computed GOSUBs from my basic days :)

There is actually a neat feature where you can take the address of the thing you're assigning in a static context:

static void* address = &address;

This is helpful for things that take void* context pointers that you want to match with logical equality.

Re: Things Rust shipped without

#112

Post by GFK_of_xmaspast » Fri, Jul 03, 2015, 9:44 PM UTC

haberman wrote: post #69

pcwalton wrote: post #8

Earlier quoted context omitted.

It often simplifies a lot of the compiler implementation if you only have reducible control flow. LLVM is fine with irreducible control flow, because it has to handle C, but rustc uses a CFG for the borrow checker, which is flow-sensitive. You can convert irreducible control flow to reducible control flow, but it can explode the size of the graph in pathological cases. (I don't recall whether the borrow checker actua…

At least reserve the word, in case you change your mind in the future? I guess it's too late now...

Since when does rust care about breaking changes to the language.

Re: Things Rust shipped without

#113

Post by steveklabnik » Fri, Jul 03, 2015, 9:45 PM UTC

GFK_of_xmaspast wrote: post #112

haberman wrote: post #69

Earlier quoted context omitted.

At least reserve the word, in case you change your mind in the future? I guess it's too late now...

Since when does rust care about breaking changes to the language.

Seven weeks ago today.

Re: Things Rust shipped without

#114

Post by kazinator » Fri, Jul 03, 2015, 9:47 PM UTC

IvyMike wrote: post #6

> goto (not even as a reserved word) I haven't done this for a while, but once upon a graduate program I wrote a compiler from a made-up-language (MUP) to C. MUP had some strange control structures, and if C did not have "goto", it would have been a lot more difficult to implement those structures. Since then, I have always thought languages should have a "goto" statement that human-written code is not allowed to use…

> Since then, I have always thought languages should have a "goto" statement that human-written code is not allowed to use.

It's an interesting idea.

The problem I see is that users can get around it by wrapping goto in the simplest possible macro. Then the idea has backfired: we now have goto under as many names as there are goto-using programmers. :)

Re: Things Rust shipped without

#115

Post by jcoffland » Fri, Jul 03, 2015, 9:49 PM UTC

frivoal wrote: post #92

zem wrote: post #90

Earlier quoted context omitted.

~20 years of using various combinations of C and C++, and i never knew you could take the address of a label! reminds me of computed GOSUBs from my basic days :)

And they say C is a simple language... :) To be fair, I've seen code like this exactly once.

Who says that?

Re: Things Rust shipped without

#116

Post by luso_brazilian » Fri, Jul 03, 2015, 9:50 PM UTC

derf_ wrote: post #105

bluecalm wrote: post #87

Earlier quoted context omitted.

As mentioned above, in C goto is often useful for error handling (where you need to free some resources before exiting the function). It's way more convenient and readable to write freeing code once and jump to it instead of having multiple return exits and duplicate the code before every single one of them.

What the parent said still applies in your case. You just make a wrapper function that does the cleanup. I have used this pattern many times: static int foo_impl(int arg, int **resource1, int **resource2) { *resource1 = (int *)malloc(sizeof(**resource1)); if (*resource1 == NULL) return EXIT_FAILURE; /* Do something with resource1 (omitted)... */ *resource2 = (int *)malloc(sizeof(**resource2)); if (*resource2 == NULL)…

I know it is just an example to illustrate the point but this seems to have a bug in it: resource2 won't be initialized if the function fail to allocate resource1 so resource2 will be null when the code enters the deallocation condition.

A way to fix it would be to return different failures for every allocation and to use a switch without a break to clean up, something like:

    switch (ret) {
      case EXIT_SUCCESS:
        free(resource2);
      case EXIT_FAILURE2: 
        free(resource1);
      case EXIT_FAILURE1:
        break;
    }

EDIT: added potential fix to the code. Sorry if there is any bug in the fix, my C is a little bit ... rusty.

EDIT2: fixed a bug in the fix. C is hard, let's go shopping.

EDIT3: the explanation for the bug was also wrong. It is not a memory leak for but freeing a null pointer. Fixed too.

Re: Things Rust shipped without

#117

Post by nwmcsween » Fri, Jul 03, 2015, 9:54 PM UTC

andrepd wrote: post #12

What about things that Rust shipped without that should have been included?

An effects system.

A safe stdlib - aborting on malloc failure is not safe.

Re: Things Rust shipped without

#118

Post by kazinator » Fri, Jul 03, 2015, 9:57 PM UTC

I used Common Lisp's goto (tagbody with go) to implement portable tail recursion: a "tlet" construct that looks like the "labels" syntax for defining a local function, but is just a stackless goto thunk with parameters.

http://www.kylheku.com/cgit/lisp-snippets/tree/tail-recursio...

This also provides some facilities for doing cross-module tail recursion among top-level functions. Here, continuation to the next function is provided by wrapping the function call in a closure, performing a non-local exit which abandons stack frames up to a dispatch loop, which then invokes the closure.

Re: Things Rust shipped without

#119

Post by dragonwriter » Fri, Jul 03, 2015, 10:02 PM UTC

pcwalton wrote: post #22

andresmanz wrote: post #18

I'd like Rust to be shipped without counterintuitive standard library function names and that book with all its style 'recommendations'. And I'd like the Rust compiler to be shipped without that non-snake case warning enabled by default. Language creators won't endear themselves to me by ranting. The problem I have with Rust is _not_ the language itself.

This is the first I've heard complaints that Rust is too strict with formatting. If anything, the popularity of gofmt (which is far more opinionated than rustc's default warnings are!) is a testament to the fact that people want languages to be ruthlessly opinionated regarding style these days.

> If anything, the popularity of gofmt (which is far more opinionated than rustc's default warnings are!) is a testament to the fact that people want languages to be ruthlessly opinionated regarding style these days.

Its testament to the fact that there are some people that want that; that's very different from that being what people in general want.

Re: Things Rust shipped without

#120

Post by Niten » Fri, Jul 03, 2015, 10:05 PM UTC

api wrote: post #33

sunfish wrote: post #26

Earlier quoted context omitted.

I wish C/C++ had a labeled break construct, like JavaScript, Java, Rust, and other languages have. It's surprisingly powerful, while still remaining structured. I personally have enjoyed learning about it, and about just how rarely an actual goto is really needed.

I've never had to use 'goto' in C++ except to break from a nested loop. In C++ labeled breaks would make 'goto' completely obsolete. In C it would still have use in the implementation of orderly error handling -- the pattern where you hand-implement exception handling in C by putting an on_error: label at the end of the function that is goto'd on error. The addition of some orderly construct for this in C would elimi…

> The addition of some orderly construct for this in C would eliminate that case, leaving no real role for goto there either.

I like the way this is handled in Go with the defer keyword: https://blog.golang.org/defer-panic-and-recover

This construct gives you most of the power of C++ RAII without the overhead. Except that you can't use it to cleanup resources after exiting an anonymous block—it strictly defers to function exit.