Thread overview
The `with` construct is good, but it could be great
Jul 20
jmh530
Jul 20
IGotD-
Jul 20
jmh530
Jul 20
IGotD-
July 20

The with statement is a good feature. However, a lot of people including me believe that it lacks potential to be great.

It introduces scope and cannot be used in a declarative scope.

It’s shortcomings are surprisingly similar to C++’s if constexpr that Andrei in Design by Introspection considered to be a “fatal mistake”.

Up for discussion, I’d even suggest a no-brace form for with declarations:

  • with Symbol: or with(Symbol): (like attributes)
  • with Symbol; (like import)

That implemented, with would be a great feature.

Contrary to others, I do not believe that with expressions would be necessary. The main reason with expressions are asked for is because with introduces scope.

July 20

On Wednesday, 20 July 2022 at 16:46:10 UTC, Quirin Schroll wrote:

>

[...]
Up for discussion, I’d even suggest a no-brace form for with declarations:

  • with Symbol: or with(Symbol): (like attributes)

I have implemented with(Sym):

The patch is very short and should apply cleanly
https://github.com/UplinkCoder/dmd/commit/492ea4c0e17127e82982672553e33b1b6eb0491f

July 20

On Wednesday, 20 July 2022 at 16:46:10 UTC, Quirin Schroll wrote:

>

The with statement is a good feature. However, a lot of people including me believe that it lacks potential to be great.

It introduces scope and cannot be used in a declarative scope.

It’s shortcomings are surprisingly similar to C++’s if constexpr that Andrei in Design by Introspection considered to be a “fatal mistake”.

Up for discussion, I’d even suggest a no-brace form for with declarations:

  • with Symbol: or with(Symbol): (like attributes)
  • with Symbol; (like import)

That implemented, with would be a great feature.

Contrary to others, I do not believe that with expressions would be necessary. The main reason with expressions are asked for is because with introduces scope.

with Symbol: or with(Symbol): seems natural. Would with Symbol; do the same thing? Seems harder to follow than the above.

On a recent bug report I suggested with work with import so that you could do something like with(std.math) import constants, hardware; that would be equivalent to import std.math.constants, std.math.hardware;. That seems like a natural extension.

July 20

On Wednesday, 20 July 2022 at 16:46:10 UTC, Quirin Schroll wrote:

>

Contrary to others, I do not believe that with expressions would be necessary. The main reason with expressions are asked for is because with introduces scope.

One of the big usage of "with" in C# is that the destructor (on the class that is in the with expression) is guaranteed to be run when it leaves the scope. C# is similar to D that you don't know when the destructor is executed but the "with" statement makes it deterministic.

Does D need a "with" statement? I don't know and it also depends how the libraries are written. I'm personally not completely against introducing "with" in D. D has tried to follow Rust lately but I rather see that D follows C# as it is a better fit.

July 20

On Wednesday, 20 July 2022 at 18:15:10 UTC, IGotD- wrote:

>

[snip]

Does D need a "with" statement? I don't know and it also depends how the libraries are written. I'm personally not completely against introducing "with" in D. D has tried to follow Rust lately but I rather see that D follows C# as it is a better fit.

D already has with...
https://dlang.org/spec/statement.html#with-statement

July 20

On Wednesday, 20 July 2022 at 19:21:38 UTC, jmh530 wrote:

>

D already has with...
https://dlang.org/spec/statement.html#with-statement

Wow, I totally missed that. A bit different from C# though and could certainly be expanded upon.

July 21

On Wednesday, 20 July 2022 at 16:46:10 UTC, Quirin Schroll wrote:

>

The with statement is a good feature. However, a lot of people including me believe that it lacks potential to be great.

It introduces scope and cannot be used in a declarative scope.

It’s shortcomings are surprisingly similar to C++’s if constexpr that Andrei in Design by Introspection considered to be a “fatal mistake”.

Up for discussion, I’d even suggest a no-brace form for with declarations:

  • with Symbol: or with(Symbol): (like attributes)
  • with Symbol; (like import)

That implemented, with would be a great feature.

Contrary to others, I do not believe that with expressions would be necessary. The main reason with expressions are asked for is because with introduces scope.

The main reason why with expressions are desired is so they can be used in expressions, adding a form that does not introduce a scope does not change this.

July 29

On Thursday, 21 July 2022 at 01:41:03 UTC, max haughton wrote:

>

On Wednesday, 20 July 2022 at 16:46:10 UTC, Quirin Schroll wrote:

>

The with statement is a good feature. However, a lot of people including me believe that it lacks potential to be great.

It introduces scope and cannot be used in a declarative scope.

It’s shortcomings are surprisingly similar to C++’s if constexpr that Andrei in Design by Introspection considered to be a “fatal mistake”.

Up for discussion, I’d even suggest a no-brace form for with declarations:

  • with Symbol: or with(Symbol): (like attributes)
  • with Symbol; (like import)

That implemented, with would be a great feature.

Contrary to others, I do not believe that with expressions would be necessary. The main reason with expressions are asked for is because with introduces scope.

The main reason why with expressions are desired is so they can be used in expressions, adding a form that does not introduce a scope does not change this.

Agreed, with (along with let bindings) is pretty common in functional languages which are commonly expression based. Here's an example from a language that I use on a daily basis:

July 30

On Wednesday, 20 July 2022 at 16:53:27 UTC, jmh530 wrote:

>

On a recent bug report I suggested with work with import so that you could do something like with(std.math) import constants, hardware; that would be equivalent to import std.math.constants, std.math.hardware;. That seems like a natural extension.

Unless it was special cased, that would fall back to top level imports if the modules named didn't exist in std.math. (Following usual rules for with). So when seeing with... import you'd have to be aware of that. Maybe other syntax would be clearer.

August 08

On Wednesday, 20 July 2022 at 16:53:27 UTC, jmh530 wrote:

>

On a recent bug report I suggested with work with import so that you could do something like with(std.math) import constants, hardware; that would be equivalent to import std.math.constants, std.math.hardware;. That seems like a natural extension.

What I supported in an old language is:

import std.math.(constants, hardware);

Which has the advantage of not falling back to a toplevel import if not found.
But I don't think I'll do that in my current language, because it's sort of a library smell if you need a page full of imports. Just import std;.