January 16
On 1/15/22 16:44, Paul Backus wrote:
> On Saturday, 15 January 2022 at 10:40:29 UTC, Timon Gehr wrote:
>>> And d has no problem with pure functions doing things to pointers that are passed to them anyway.
>>
>> It makes absolutely no sense that a @safe pure function can cast an int* to size_t. It violates the spec of pure functions, because pure functions can create new int* with addresses that depend on global state, so if they can in turn create integers from those, that will produce non-deterministic results.
> 
> The spec explicitly allows such non-deterministic results; it just says that the behavior of calling such a function is implementation-defined:
> ...

Sorry, it's just not a fair reading of that paragraph to claim that it is "explicitly allowed" or that it "just" says the result is implementation-defined. Clearly UB is terrible, so this is the best solution, particularly if you don't want to explain what "equivalent" means.

>> **Implementation Defined:** An implementation may assume that a strongly pure function that returns a result without mutable indirections will have the same effect for all invocations with equivalent arguments. It is allowed to memoize the result of the function under the assumption that equivalent parameters always produce equivalent results. *A strongly pure function may still have behavior inconsistent with memoization by e.g. using casts or by changing behavior depending on the address of its parameters.* An implementation is currently not required to enforce validity of memoization in all cases.
> 
> (From https://dlang.org/spec/function.html#pure-functions. Emphasis added.)

*currently not required*.

This is one of those instances where the specification was changed to document undesirable behavior in the meantime before it is fixed in the language. It's not something that DIPs should rely on as a foundation.


January 16
On 1/15/22 13:02, Elronnd wrote:
> I will add: pure does not mean @safe.  The following program prints 17 on my computer with a recent dmd, for instance:
> 
> pure int f(int *x) {
>      return x[1];
> }
> int main() {
>      import std.stdio;
>      int x, y = 17;
>      writeln(f(&x));
>      return y;
> }

About this, this is fine. `pure` has a meaning. In @system code it is up to the programmer to ensure this meaning is respected, where the language can provide some assistance with sane defaults. But in @safe code, it's on the language, with some assistance of @trusted assumptions.
January 17

On Monday, 10 January 2022 at 13:48:14 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community Review of DIP 1042, "ProtoObject":

[...]

Given the amount of debate that this DIP has provoked, I wonder if it was worthwhile to have a universal base class in D in the first place.

April 03

On Monday, 17 January 2022 at 15:01:51 UTC, Mark wrote:

>

On Monday, 10 January 2022 at 13:48:14 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community Review of DIP 1042, "ProtoObject":

[...]

Given the amount of debate that this DIP has provoked, I wonder if it was worthwhile to have a universal base class in D in the first place.

The need for some universal, untainted base class has been implicitly voiced already in Bugzilla! See https://issues.dlang.org/show_bug.cgi?id=9771

April 04

On Monday, 17 January 2022 at 15:01:51 UTC, Mark wrote:

>

On Monday, 10 January 2022 at 13:48:14 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community Review of DIP 1042, "ProtoObject":

[...]

Given the amount of debate that this DIP has provoked, I wonder if it was worthwhile to have a universal base class in D in the first place.

Given the metaprogramming capabilities of D, I'm surprised it is still needed today.

There is lot to learn from Go, and its struct based composition model, runtime reflection and a GC without needing a base class! Moving forward, I think that is a model to take inspiration from.

April 04

On Monday, 4 April 2022 at 09:39:34 UTC, ryuukk_ wrote:

>

and a GC without needing a base class!

D does not need to have a base class for its GC to work with class instances either.
Just typeinfo that store the dtor address.

Next ›   Last »
1 2 3 4 5 6 7 8 9