The main reason for "do"'s existence is to make task spawning look nice. The
closure inference was removed throughout the language because it masked
allocation and doesn't work well with custom smart pointers. If "do" is still
causing confusion, I'd rather just remove it entirely.
Patrick
Chris Morgan <m...@chrismorgan.info> wrote:
>(Do I win the prize for the shortest thread name yet?)
>
>> error: last argument in `do` call has non-procedure type: ||
>
>In the past three or four days I've seen at least as many enquiries in
>#rust about this error, and I'm sure there have been at least several
>others while I haven't been monitoring it. This is evidently causing
>quite a bit of confusion.
>
>Here's a summary of the change. The syntax is the same as it was
>before::
>
> do expr { block }
> do expr |args| { block }
> do expr(args) { block }
> do expr(args) |args| { block }
>
>These used to desugar to the following, respectively::
>
> expr(|| { block })
> expr(|args| { block })
> expr(args, || { block })
> expr(args, |args| { block })
>
>These now desugar to the following, respectively::
>
> expr(proc() { block })
> expr(proc(args) { block })
> expr(args, proc() { block })
> expr(args, proc(args) { block })
>
>The change is that it now accepts a procedure rather than a closure.
>No syntax change, just a semantics change which breaks a lot of code.
>
>Closure: a stack function; used to be ``&fn(..) -> _``, is now ``|..|
>-> _``. Can be called multiple times, requires no allocations and is
>not Send.
>
>Procedure: a heap function; used to be ``~once fn(..) -> _``, is now
>``proc(..) -> _``. Can be called once, requires heap allocation and is
>Send.
>
>Procedures are good for sending cross-task; things like the task body
>are a good match. Still, I think there are a few problems with how
>things are at present (i.e. after the do semantics change):
>
>1. ``do`` is still using the syntax of a closure (``|..| { .. }``),
>despite it now being a procedure.
>
>2. All of a sudden, things using closures need to shift away from
>using ``do`` or use procedures; this is causing confusion and may
>cause bad design decisions where nice sugar triumphs over what is
>actually needed; often the best solution may not be clear. (I, for
>example, had not thought about the fact that ``proc`` was going to
>allocate; the ``~once fn`` name was clearer about that. I'll speak
>about ``&once fn`` another time. Don't mention it now, this thread is
>just about ``do``.)
>
>I have two solutions that I think could answer these concerns. Leaving
>it as it is seems a bad idea to me.
>
>(a) Kill ``do``
>---------------
>
>I've had mixed feelings about ``do``. Overall, it's pretty trivial
>syntax sugar, but it's sugar of a dubious sort, because it changes
>something that looks like a function call with N arguments to be a
>function call with N+1 arguments. That's just a matter of learning it.
>
>Still, ``do`` *is* nice sugar in the way it gets rid of parentheses at
>the end. Overall, is it worth it? I don't know.
>
>Once ``do`` is gone, there's no problem left: just remove the sugar
>*everywhere* it was used and everything works and will do for the
>foreseeable future.
>
>(b) Make ``do`` support both closures and procedures
>----------------------------------------------------
>
>The syntax of ``do`` can be clearly seen to include the closure
>syntax. We could easily extend it to support both closures and
>procedures.
>
>Here is a proposed ``do`` using closures once more, keeping the syntax
>it had last week::
>
> do expr || { block }
> do expr(args) || { block }
> do expr |args| { block }
> do expr(args) |args| { block }
>
>Here is a proposed ``do`` using procedures as the current behaviour
>is, but with new syntax which is clearly a procedure::
>
> do expr proc() { block }
> do expr(args) proc() { block }
> do expr proc(args) { block }
> do expr(args) proc(args) { block }
>
>This does leave these cases which are currently valid unclear::
>
> do expr { block }
> do expr(args) { block }
>
>The options for this are (a) disallowing it; (b) making it always of
>the function types; and (c) inferring the type. I generally prefer the
>last solution but it is the most difficult. I'm not sure how it all
>fits into the function traits stuff at all.
>
>Incidentally, all this leaves the possibility open of making ``do``
>work for *any* argument type, where ``do expr1 expr2`` simply desugars
>to ``expr1(expr2)`` and ``do expr1(args) expr2`` to ``do expr1(args,
>expr2)``. I don't know if that would be a good thing or not; it's
>probably best to avoid discussion of that at present.
>
>Summary
>=======
>
>Leaving ``do`` in its present form seems to me a distinctly bad idea,
>with the syntax of one form of function while it uses another form of
>function. I think we need to redo ``do`` very soon. (I'd save this
>joke for later in the thread, but I'm afraid someone else might steal
>it. I expect all responses to indicate they're in favour of this by
>using the title "Re: do" :P.)
>
>For myself, I have no preference to indicate; I am torn between the two
>options.
>_______________________________________________
>Rust-dev mailing list
>Rust-dev@mozilla.org
>https://mail.mozilla.org/listinfo/rust-dev
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity._______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
