> I don't think this flies anyway. It has to be more like a function body,
otherwise var and function declarations would hoist out of it, which would
be insane IMO.
Agreed.
> Also, I really would want to avoid examples like [..]
Agreed.
> IIUC, the goal here is to allow a sequence of statements to produce a
value, not (necessarily) to allow arbitrary block semantics.
Agreed.
> strict function declarations don't hoist out of blocks, so the hoisting
issue is var only. I would find it surprising if var declarations did not
hoist out of do expressions.
If the intention is to have do-as-IIFE, then it would surprising to see var
host outside of a do expression.
> If all we want is sugar for IIFEs, I wouldn't bother. With arrow
functions, IIFEs are already a lot shorter. The extra brevity of do
expressions is not worth it.
I disagree. It is nice to be able to define a one-off IIFE. Furthermore,
wouldn't this allow a simpler GC implementation?
> I find the do{} solution more elegant and I believe this pattern ()=>{}()
will be abused pretty soon and JS will start looking like brainfuck but
that's another story I guess.
Agreed.
> I do have one usability concern with arrow IIFEs. I hate when I see them
written as ()=>{...whatever...}() because you don't know that it's an IIFE
until the end. Function expressions have the same issue.
Good point.
> Rather, I suggest that the following must work:> while (true) { do {
break; } }
I am surprised by this requirement. I don't think `do` should serve allow
control flow statements at all.
I would argue that `do` expression would be mostly useful for promoting use
of `const`, e.g.,
    _.map(groupedEvents, (locationEvents) => {        let locationName;
        const locationEvent = locationEvents[0];
        if (locationEvent.locationDisplayName) {            locationName =
locationEvent.locationDisplayName;        } else if
(locationEvent.cinemaIsPlatform)
{            locationName = locationEvent.locationName;        } else if (
isCinemaNamePartOfLocationName(locationEvent.locationName,
locationEvent.cinemaName)) {            locationName =
locationEvent.locationName;        } else {            locationName =
locationEvent.cinemaName + ' ' + locationEvent.locationName;        }
        // ...
I would like to avoid using `let` in this case and `do` expression is great
for this:
    _.map(groupedEvents, (locationEvents) => {        let locationName;
        const locationEvent = locationEvents[0];
        const locationName = do {            if
(locationEvent.locationDisplayName)
{                locationEvent.locationDisplayName;            } else if
(locationEvent.cinemaIsPlatform) {
locationEvent.locationName;            } else if (
isCinemaNamePartOfLocationName(locationEvent.locationName,
locationEvent.cinemaName)) {                locationEvent.locationName;
        } else {                locationEvent.cinemaName + ' ' +
locationEvent.locationName;            }        };
        // ...
However, I do not like at all that `do` expression returns value of the
last statement. I would much rather prefer to have `return` to be able to
control return of the value within `do` expression, e.g.
    _.map(groupedEvents, (locationEvents) => {        let locationName;
        const locationEvent = locationEvents[0];
        const locationName = do {            if
(locationEvent.locationDisplayName)
{                return locationEvent.locationDisplayName;            }
            if (locationEvent.cinemaIsPlatform) {                return
locationEvent.locationName;            }
            if (isCinemaNamePartOfLocationName(locationEvent.locationName,
locationEvent.cinemaName)) {                return
locationEvent.locationName;            }
            return locationEvent.cinemaName + ' ' +
locationEvent.locationName;        };
        // ...
Has this discussion been moved to some other medium?
No messages have been exchanged since 2014. In the mean time, transpilers
such as Babel have implemented the proposal (
http://babeljs.io/docs/plugins/transform-do-expressions/) and are
"promoting" its use in the form of the original proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160503/7fdd16f4/attachment.html>

> I don't think this flies anyway. It has to be more like a function body, otherwise var and function declarations would hoist out of it, which would be insane IMO.

Agreed.

> Also, I really would want to avoid examples like [..]

Agreed.

> IIUC, the goal here is to allow a sequence of statements to produce a value, not (necessarily) to allow arbitrary block semantics.

Agreed.

> strict function declarations don't hoist out of blocks, so the hoisting issue is var only. I would find it surprising if var declarations did not hoist out of do expressions.

If the intention is to have do-as-IIFE, then it would surprising to see var host outside of a do expression.

> If all we want is sugar for IIFEs, I wouldn't bother. With arrow functions, IIFEs are already a lot shorter. The extra brevity of do expressions is not worth it.

I disagree. It is nice to be able to define a one-off IIFE. Furthermore, wouldn't this allow a simpler GC implementation?

> I find the do{} solution more elegant and I believe this pattern ()=>{}() will be abused pretty soon and JS will start looking like brainfuck but that's another story I guess.

Agreed.

> I do have one usability concern with arrow IIFEs. I hate when I see them written as ()=>{...whatever...}() because you don't know that it's an IIFE until the end. Function expressions have the same issue.

Good point.

> Rather, I suggest that the following must work:
> while (true) { do { break; } }

I am surprised by this requirement. I don't think that `do` expression should allow control flow statements at all (of the block in which it is contained).

I would argue that `do` expression would be mostly useful for promoting use of `const`, e.g.,

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        if (locationEvent.locationDisplayName) {
            locationName = locationEvent.locationDisplayName;
        } else if (locationEvent.cinemaIsPlatform) {
            locationName = locationEvent.locationName;
        } else if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
            locationName = locationEvent.locationName;
        } else {
            locationName = locationEvent.cinemaName + ' ' + locationEvent.locationName;
        }

        // ...

I would like to avoid using `let` in this case and `do` expression is great for this:

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        const locationName = do {
            if (locationEvent.locationDisplayName) {
                locationEvent.locationDisplayName;
            } else if (locationEvent.cinemaIsPlatform) {
                locationEvent.locationName;
            } else if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
                locationEvent.locationName;
            } else {
                locationEvent.cinemaName + ' ' + locationEvent.locationName;
            }
        };

        // ...

However, I do not like at all that `do` expression returns value of the last statement. I would much rather prefer to have `return` to be able to control return of the value within `do` expression, e.g.

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        const locationName = do {
            if (locationEvent.locationDisplayName) {
                return locationEvent.locationDisplayName;
            }

            if (locationEvent.cinemaIsPlatform) {
                return locationEvent.locationName;
            }

            if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
                return locationEvent.locationName;
            }

            return locationEvent.cinemaName + ' ' + locationEvent.locationName;
        };

        // ...

Has this discussion been moved to some other medium?

No messages have been exchanged since 2014. In the mean time, transpilers such as Babel have implemented the proposal (http://babeljs.io/docs/plugins/transform-do-expressions/) and are "promoting" its use in the form of the original proposal.

> I don't think this flies anyway. It has to be more like a function body, otherwise var and function declarations would hoist out of it, which would be insane IMO.

Agreed.

> Also, I really would want to avoid examples like [..]

Agreed.

> IIUC, the goal here is to allow a sequence of statements to produce a value, not (necessarily) to allow arbitrary block semantics.

Agreed.

> strict function declarations don't hoist out of blocks, so the hoisting issue is var only. I would find it surprising if var declarations did not hoist out of do expressions.

If the intention is to have do-as-IIFE, then it would surprising to see var host outside of a do expression.

> If all we want is sugar for IIFEs, I wouldn't bother. With arrow functions, IIFEs are already a lot shorter. The extra brevity of do expressions is not worth it.

I disagree. It is nice to be able to define a one-off IIFE. Furthermore, wouldn't this allow a simpler GC implementation?

> I find the do{} solution more elegant and I believe this pattern ()=>{}() will be abused pretty soon and JS will start looking like brainfuck but that's another story I guess.

Agreed.

> I do have one usability concern with arrow IIFEs. I hate when I see them written as ()=>{...whatever...}() because you don't know that it's an IIFE until the end. Function expressions have the same issue.

Good point.

> Rather, I suggest that the following must work:
> while (true) { do { break; } }

I am surprised by this requirement. I don't think that `do` expression should allow control flow statements at all.

I would argue that `do` expression would be mostly useful for promoting use of `const`, e.g.,

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        if (locationEvent.locationDisplayName) {
            locationName = locationEvent.locationDisplayName;
        } else if (locationEvent.cinemaIsPlatform) {
            locationName = locationEvent.locationName;
        } else if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
            locationName = locationEvent.locationName;
        } else {
            locationName = locationEvent.cinemaName + ' ' + locationEvent.locationName;
        }

        // ...

I would like to avoid using `let` in this case and `do` expression is great for this:

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        const locationName = do {
            if (locationEvent.locationDisplayName) {
                locationEvent.locationDisplayName;
            } else if (locationEvent.cinemaIsPlatform) {
                locationEvent.locationName;
            } else if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
                locationEvent.locationName;
            } else {
                locationEvent.cinemaName + ' ' + locationEvent.locationName;
            }
        };

        // ...

However, I do not like at all that `do` expression returns value of the last statement. I would much rather prefer to have `return` to be able to control return of the value within `do` expression, e.g.

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        const locationName = do {
            if (locationEvent.locationDisplayName) {
                return locationEvent.locationDisplayName;
            }

            if (locationEvent.cinemaIsPlatform) {
                return locationEvent.locationName;
            }

            if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
                return locationEvent.locationName;
            }

            return locationEvent.cinemaName + ' ' + locationEvent.locationName;
        };

        // ...

Has this discussion been moved to some other medium?

No messages have been exchanged since 2014. In the mean time, transpilers such as Babel have implemented the proposal (http://babeljs.io/docs/plugins/transform-do-expressions/) and are "promoting" its use in the form of the original proposal.

> I don't think this flies anyway. It has to be more like a function body, otherwise var and function declarations would hoist out of it, which would be insane IMO.

Agreed.

> Also, I really would want to avoid examples like [..]

Agreed.

> IIUC, the goal here is to allow a sequence of statements to produce a value, not (necessarily) to allow arbitrary block semantics.

Agreed.

> strict function declarations don't hoist out of blocks, so the hoisting issue is var only. I would find it surprising if var declarations did not hoist out of do expressions.

If the intention is to have do-as-IIFE, then it would surprising to see var host outside of a do expression.

> If all we want is sugar for IIFEs, I wouldn't bother. With arrow functions, IIFEs are already a lot shorter. The extra brevity of do expressions is not worth it.

I disagree. It is nice to be able to define a one-off IIFE. Furthermore, wouldn't this allow a simpler GC implementation?

> I find the do{} solution more elegant and I believe this pattern ()=>{}() will be abused pretty soon and JS will start looking like brainfuck but that's another story I guess.

Agreed.

> I do have one usability concern with arrow IIFEs. I hate when I see them written as ()=>{...whatever...}() because you don't know that it's an IIFE until the end. Function expressions have the same issue.

Good point.

> Rather, I suggest that the following must work:
> while (true) { do { break; } }

I am surprised by this requirement. I don't think `do` expression should allow control flow statements at all.

I would argue that `do` expression would be mostly useful for promoting use of `const`, e.g.,

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        if (locationEvent.locationDisplayName) {
            locationName = locationEvent.locationDisplayName;
        } else if (locationEvent.cinemaIsPlatform) {
            locationName = locationEvent.locationName;
        } else if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
            locationName = locationEvent.locationName;
        } else {
            locationName = locationEvent.cinemaName + ' ' + locationEvent.locationName;
        }

        // ...

I would like to avoid using `let` in this case and `do` expression is great for this:

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        const locationName = do {
            if (locationEvent.locationDisplayName) {
                locationEvent.locationDisplayName;
            } else if (locationEvent.cinemaIsPlatform) {
                locationEvent.locationName;
            } else if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
                locationEvent.locationName;
            } else {
                locationEvent.cinemaName + ' ' + locationEvent.locationName;
            }
        };

        // ...

However, I do not like at all that `do` expression returns value of the last statement. I would much rather prefer to have `return` to be able to control return of the value within `do` expression, e.g.

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        const locationName = do {
            if (locationEvent.locationDisplayName) {
                return locationEvent.locationDisplayName;
            }

            if (locationEvent.cinemaIsPlatform) {
                return locationEvent.locationName;
            }

            if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
                return locationEvent.locationName;
            }

            return locationEvent.cinemaName + ' ' + locationEvent.locationName;
        };

        // ...

Has this discussion been moved to some other medium?

No messages have been exchanged since 2014. In the mean time, transpilers such as Babel have implemented the proposal (http://babeljs.io/docs/plugins/transform-do-expressions/) and are "promoting" its use in the form of the original proposal.

> I don't think this flies anyway. It has to be more like a function body, otherwise var and function declarations would hoist out of it, which would be insane IMO.

Agreed.

> Also, I really would want to avoid examples like [..]

Agreed.

> IIUC, the goal here is to allow a sequence of statements to produce a value, not (necessarily) to allow arbitrary block semantics.

Agreed.

> strict function declarations don't hoist out of blocks, so the hoisting issue is var only. I would find it surprising if var declarations did not hoist out of do expressions.

If the intention is to have do-as-IIFE, then it would surprising to see var host outside of a do expression.

> If all we want is sugar for IIFEs, I wouldn't bother. With arrow functions, IIFEs are already a lot shorter. The extra brevity of do expressions is not worth it.

I disagree. It is nice to be able to define a one-off IIFE. Furthermore, wouldn't this allow a simpler GC implementation?

> I find the do{} solution more elegant and I believe this pattern ()=>{}() will be abused pretty soon and JS will start looking like brainfuck but that's another story I guess.

Agreed.

> I do have one usability concern with arrow IIFEs. I hate when I see them written as ()=>{...whatever...}() because you don't know that it's an IIFE until the end. Function expressions have the same issue.

Good point.

> Rather, I suggest that the following must work:
> while (true) { do { break; } }

I am surprised by this requirement. I don't think `do` should serve allow control flow statements at all.

I would argue that `do` expression would be mostly useful for promoting use of `const`, e.g.,

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        if (locationEvent.locationDisplayName) {
            locationName = locationEvent.locationDisplayName;
        } else if (locationEvent.cinemaIsPlatform) {
            locationName = locationEvent.locationName;
        } else if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
            locationName = locationEvent.locationName;
        } else {
            locationName = locationEvent.cinemaName + ' ' + locationEvent.locationName;
        }

        // ...

I would like to avoid using `let` in this case and `do` expression is great for this:

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        const locationName = do {
            if (locationEvent.locationDisplayName) {
                locationEvent.locationDisplayName;
            } else if (locationEvent.cinemaIsPlatform) {
                locationEvent.locationName;
            } else if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
                locationEvent.locationName;
            } else {
                locationEvent.cinemaName + ' ' + locationEvent.locationName;
            }
        };

        // ...

However, I do not like at all that `do` expression returns value of the last statement. I would much rather prefer to have `return` to be able to control return of the value within `do` expression, e.g.

    _.map(groupedEvents, (locationEvents) => {
        let locationName;

        const locationEvent = locationEvents[0];

        const locationName = do {
            if (locationEvent.locationDisplayName) {
                return locationEvent.locationDisplayName;
            }

            if (locationEvent.cinemaIsPlatform) {
                return locationEvent.locationName;
            }

            if (isCinemaNamePartOfLocationName(locationEvent.locationName, locationEvent.cinemaName)) {
                return locationEvent.locationName;
            }

            return locationEvent.cinemaName + ' ' + locationEvent.locationName;
        };

        // ...

Has this discussion been moved to some other medium?

No messages have been exchanged since 2014. In the mean time, transpilers such as Babel have implemented the proposal (http://babeljs.io/docs/plugins/transform-do-expressions/) and are "promoting" its use in the form of the original proposal.