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.
Photon v0.1.1 is out!
I've been revising the cira 2018 code of Photon and realized it's quite well designed for a public beta. Examples The use of std.net.curl augmented by Photon to scale well: https://github.com/DmitryOlshansky/photon/blob/master/tests/curl_download.d Other syntetic tests may serve as examples: https://github.com/DmitryOlshansky/photon/tree/master/tests Github: https://github.com/DmitryOlshansky/photon DUB: https://code.dlang.org/packages/photon -- Dmitry Olshansky
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.
