Re: D Language Foundation March 2023 Monthly Meeting Summary
On Thursday, 13 April 2023 at 01:44:24 UTC, Walter Bright wrote: On 4/11/2023 7:35 PM, bachmeier wrote: [...] It's a seductive idea, and I've considered that (and variations on it) many times. We have done this, after a fashion, in having our own versions of the .h files in the form of the D translations in core.stdc.* import files. [...] I've now lost count of how many times changes in the Python headers break code using it. The only way to consume headers is to parse/translate/etc. them on the fly.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote: __Resolving disagreements__ Well that's disappointing. I guess DMD will just continue to bleed contributors whenever Walter decides to do something that the entire contributor base that is a very bad idea.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On 4/11/2023 7:35 PM, bachmeier wrote: Can't the changes to those files by stored in the compiler? Walter obviously can't change the raw header files, but he can make changes to the files before they're used by the compiler. If that's not possible, can't a modified set of header files be available for download, and if you want to use a system .h file, you have to use the modified version instead? It's a seductive idea, and I've considered that (and variations on it) many times. We have done this, after a fashion, in having our own versions of the .h files in the form of the D translations in core.stdc.* import files. The trouble is, there are endless C .h files out there, and they change essentially randomly. We've been tripped up with this by the windows .h files changing and breaking our translations of them in druntime. It's made worse by there being no way for us to realize those .h files have changed, while we merrily keep using the existing translations. Diemos has also had constant problems with changing .h files, which only gets discovered when a user runs into a problem. A huge point to ImportC is to become resistant to arbitrary changes by compiling whatever those .h files happen to be. Since we don't have an army of people willing to constantly create our own versions of the .h files, it's our only practical option. You can see some of the adaptations for specific .h wackiness in druntime's importc.h and _builtins.di files.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote: The language shouldn't support by default making a storage allocator pure. It's doing its job, saying you can't do this because you're changing state. So you have to fake it by doing a dirty cast in there somewhere. The reason why D supports system code is so you can do dirty things when you have to. It's the same with `const`. D does not support logical const, because logical const is not const. It's not enforceable. That's a feature. If you want logical const, you have to do something dirty to get it, and that's appropriate. No, these are different. `pure` only says the compiler is allowed to cache the result of a function and reuse it for similar calls. You are allowed to do debug logging, or return different results with subsequent calls (by casting an impure function to `pure`), as long as you accept that this results in unspecified behaviour. This means marking a custom allocator `pure` is okay (the [pure factory function](https://dlang.org/spec/function.html#pure-factory-functions) rule forbids the compiler from caching the memory address of the returned result). On the other hand, mutating anything through a `const` reference is not only unspecific behafiour, it is un*defined* behaviour. The compiler may simply assume you don't do this, so if you do, anything may happen. Any D program using `const` as "logical" is excommunicated by the spec. With `pure` hacks, there's more than one thing that may happen, but the options are still limited. With `const` hacks, they are not. The former are dirty hacks but legal, the latter are totally illegal. It they are intended to be the same, the spec needs changes.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote:
Walter also said that whether void initialization should be
allowed in pure code is a different question. Void initializing
an int and returning it isn't pure, is it? So maybe we should
disallow void initializations in pure code. He thinks that's a
reasonable proposition.
I disagree: it makes sense as is. Consider:
```D
@safe pure int fun()
{ int result = void;
return result;
}
@safe void gun()
{ int a = fun(), b = fun();
[a, b].each!writeln;
}
```
What are values of `a` and `b`? They are unspecified. Since `fun`
is pure, the compiler might cache the unspecified value of `a =
fun()` to `b`, but so what? `b` is also unspecified, so it's
expected it could happen to always be same as `a`.
`pure` can and should be able to return unspecified values, as
long as they're unspecified the same way for the same argument
set. About what would be unspecified in different way, and thus
impure, this is an example:
```D
int global;
@safe int impureFun()
{ int local = void;
if (local < global) return global;
else return local;
}
```
This also returns an unspecified value (unless `global ==
int.max`) but it's unspecified in different way depending on
global state (never less than `global` at time of call) so the
compiler rightfully rejects it if you try to mark it `pure`.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote: The monthly meeting for March took place on March 3rd, 2023, at 14:30 UTC, and lasted about an hour and fifteen minutes. The following people attended: As before, a great deal of interesting stuff here. Also useful: with these we aren't left guessing what the Foundation is thinking. We have a much better idea about what kind of ranting could be of value.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Tuesday, 11 April 2023 at 21:53:50 UTC, Mike Parker wrote: ImportC was slowly grinding along. His priority was getting all the standard header files to compile on all the platforms. A lot of the system `.h` files on the various platforms have made a feeble attempt to be usable by different compilers but fail miserably, and each one fails in its unique fashion. They'd be easy to fix if he could edit those files, but of course, he can't. Can't the changes to those files by stored in the compiler? Walter obviously can't change the raw header files, but he can make changes to the files before they're used by the compiler. If that's not possible, can't a modified set of header files be available for download, and if you want to use a system .h file, you have to use the modified version instead?
Re: D Language Foundation March 2023 Monthly Meeting Summary
Finally, he asked what everyone thought about including Phobos in the dmd/druntime mono repository. He said he'd seen no good reason not to [in the forum thread he'd started](https://forum.dlang.org/thread/kdgcznersjetunkvo...@forum.dlang.org). Iain said that from his perspective, DRuntime and Phobos are the same thing anyway. Mathias voiced support for it. Robert said that if it happened, the first thing he'd do is replace some instances of `filter` with the Phobos version, as he thinks we should be using Phobos in DMD anyway. (Note that no final decision was made here.) When I type dmd into my browsers search bar this is what it suggests: dmd/druntime at master · dlang/dmd · GitHub Not very compiler related now is it ;) __Template lowerings in CTFE__ One problem he'd discovered was that the semantic routines take several constructs and lower them to templates. They do that even when running in CTFE. Those templates can generate a lot of bloat. In CTFE, it should not do the lowering. CTFE finds it much easier to interpret the higher-level code. Upon investigation, he found that CTFE reverses some of the lowerings so that it can interpret them. If you're doing certain things in CTFE like array concatenation, you're suffering from a lot of invisible template bloat. That needs to be fixed. He was about halfway through it. He was looking at all the lowerings and rewriting them so that the lowering isn't done in CTFE. He hopes that this is another step in reducing the problems with memory consumption and slow CTFE speeds. He also hoped to be able to remove the "lowering unwinding" that goes on in the interpreter. Iain noted that in [the PR rewriting the `_d_newclass` runtime hook to a template](https://forum.dlang.org/post/fmzqqpzrzhoheylue...@forum.dlang.org), he'd noticed the same thing Walter had just described. He got the author to change things such that rather than doing this lowering->unlowering->relowering thing, the rewrite is put into a field called `lowering`, leaving the original node intact. When you go through CTFE, you just work on that node specifically. Then once you're in codegen, you hit that node and go into the `lowering` field. Walter said that wasn't done with the other rewrites, but Teodor Dutu and Razvan plan to go back and change them (here's [an example of work done toward that end](https://github.com/dlang/dmd/pull/14985)). Walter said this will also be a big win for allowing more expansive use of CTFE in BetterC. Good to see my priority two for the year is getting some work done towards it by happenstance. Now, if only we could get a compiler adjacent library to contain the hooks so nobody writing custom runtimes has to write them moving forward... That and getting them all in the same place has other benefits like faster compiles!
D Language Foundation March 2023 Monthly Meeting Summary
The monthly meeting for March took place on March 3rd, 2023, at 14:30 UTC, and lasted about an hour and fifteen minutes. The following people attended: * Walter Bright * Iain Buclaw * Ali Çehreli * Martin Kinkelin * Dennis Korpel * Mathias Lang * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek ## The summary ### Dennis Dennis had nothing for us this time. ### Robert Robert had nothing other than to say that the compiler is still too slow and he still likes D. ### Razvan __Preview Switches__ Razvan had been looking at the reported issues for `-preview=nosharedaccess` and had found only a handful from Átila. This suggests that either we have a good implementation without many bugs, or it isn't being used very much. Átila suggested no one is using it at all. Razvan noted that [one of the bugs Átila had reported](https://issues.dlang.org/show_bug.cgi?id=23709) was that trying to instantiate a shared class resulted in an error. If that doesn't work, there may be other issues. He wondered what path we could take to get to where the preview becomes the default. Other than waiting for people to use it and report bugs on it, what can we do? Átila said he had been trying to get Phobos and DRuntime to compile with it, and then once they do, try it on dub packages. He said he'd encountered so much noise, he decided to wait until the bugs he'd reported are fixed before reporting more. Iain suggested we should have a pipeline that builds with all preview switches turned on by default. Dennis noted that would be a problem with preview switches that are broken. Mathias asked what a good litmus test for previews would look like. He'd had problems with `nosharedaccess` and `rvaluerefparam` not working when he tried them, then he'd given up on previews. Átila didn't know a good litmus test but was working on going through the previews and deciding on either making it the default or scrapping it, especially the ones that had been there for years, so that they aren't left in limbo. I suggested that at some point on the other side of our organizational build-up, we establish a policy for periodic reviews of previews. Razvan said his main question is whether preview switches are serving their intended purpose. They were started so that people could test new features before they are officially part of the language, but in practice, it seems they are rarely used. He thinks we should have a different mechanism to ensure new features are tested before they are merged into a compiler release, then once they are merged they're ready for use. The preview switch seems to him like a graveyard for features. I said that seems like a communication issue. Right now, we just throw a feature behind a preview switch and do nothing beyond that. I suggested we come up with a staged process that motivates people to use the previews. Robert would go a step further. He thinks there should be a burden on anyone wanting to merge a new feature to test the feature with the list of dub packages that get tested with new compiler releases, then investigate any errors. The top 30 or whatever packages should compile both with and without the preview before it's allowed in. Átila agreed. Mathias said the idea of the preview is fine and it can work. We just need to take it seriously. He said he agrees with Robert. When he implemented `-preview=in`, he did exactly what Robert suggested. [He enabled it by default](https://github.com/dlang/dmd/pull/11632) and then examined what it broke. Generally, previews are implemented with half-baked code and we don't test if they work. We need to ensure that people implementing previews do the work correctly. Walter said we could submit a pull request for each preview feature to turn it on by default. We don't have to merge them. That would ensure that it's run through BuildKite (which tests several dub packages), and we'll have links to everything that breaks. Then we reach out to the maintainers of broken packages to help upgrade their code. In the end, we decided that Razvan and Átila will gather up issues with all of the preview switches and we can decide their fates at future meetings. __@system and pure__ Razvan said that once in a while there are issues with `@system` and code and `pure`. He says that trying to do system-level things, like allocating memory without initializing it, can clash with purity, whereas in `@safe` code purity will usually be compatible. But then you can do something like void initialize a stack variable in `@safe` code and return it, and now you have this clash between two concepts. Looking forward to the day when safety and DIP1000 become the default, he was wondering if there's a way we can enforce that safety and purity don't go along together. This led to a side discussion about why people would do things like allocating memory without initializing it. Robert said that whether they
