const VS features detection

Gajus Kuizinas gajus at gajus.com
Tue May 3 20:02:14 UTC 2016


> 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>


More information about the es-discuss mailing list