Relationship to do-expressions

[littledan]

The do expressions proposal is at Stage 1, and there are some serious concerns that some TC39 members have about it (especially about completion values). Does this proposal depend on do expressions? I don't see do expressions as part of the specification here. If there is no dependency, I'd suggest moving examples based on do expressions into a separate section, to make the lack of dependency clear.

[js-choi]

Thanks for the read. I will see what I can do about isolating do-expression-using examples into their own subsections.

As for whether smart pipelines require do expressions, the answer is no, although they would be pretty nice. Pasting from tc39/proposal-pipeline-operator#100 (comment):

@js-choi Does your proposal require do expressions in order to fully function?

It does not, insofar that “fully” functioning here indicates a minimum baseline of usefulness for the developer. do expressions are a Very Nice To Have thing because they enable the embedding of if else statements, try catch finally statements, and switch statements: all frequently involved in the transformation of values. In addition, do acts as a way to create a “topic-context block”, something like Perl 6’s given block—within this block, statements may use the topic reference may be used as an abbreviation for the same value—such as the new Whatever() |> do { #.commonThing(123); ::rareAndComplexThing(321); } example from tc39/proposal-pipeline-operator#101 (comment)). I would expect do expressions to be used as pipeline bodies so frequently, I also introduced Additional Feature BP as a compatible abbreviation for them. But Additional Feature BP is strictly optional.

do expressions are immensely useful, but they are useful in the same sense that embedding them in any nested expression in general is useful. The rules of topic style in the Core Proposal do not specially treat do expressions. do expressions are not necessary to the smart-pipelines proposal; they are additive and orthogonal.