On Sunday, 18 July 2021 at 10:02:07 UTC, ag0aep6g wrote:
On 17.07.21 15:56, ag0aep6g wrote:
+1.
IMO,`strong pure` is `the outside world` has no impact on me.
`Funcs` don't have any `indirect`.
On 17.07.21 15:56, ag0aep6g wrote:
At a glance, the only meaningful use of `PURE.strong` seems to be in
dcast.d, introduced by the PR you linked. Changing that to `PURE.const_`
doesn't break any tests for me. So I'm inclined to believe that
`PURE.strong` is nonsense, and that `PURE.const_` alre
On 17.07.21 14:56, Dennis wrote:
On Saturday, 17 July 2021 at 12:05:44 UTC, ag0aep6g wrote:
Hm, as far as I understand, "strongly pure" doesn't require
`immutable` parameters. `const` should be enough. The spec says: "A
strongly pure function has no parameters with mutable indirections" [1].
On 18/07/2021 12:56 AM, Dennis wrote:
I don't know whether the spec or code is correct.
Unless otherwise specified, the code is authoritative.
On Saturday, 17 July 2021 at 12:05:44 UTC, ag0aep6g wrote:
Hm, as far as I understand, "strongly pure" doesn't require
`immutable` parameters. `const` should be enough. The spec
says: "A strongly pure function has no parameters with mutable
indirections" [1].
I just took the description from
On 17.07.21 13:05, Dennis wrote:
There used to be a complex `isReturnIsolated` check, but the [fix for
issue 15660](https://github.com/dlang/dmd/pull/8048) reduced it to a
check 'is the function strongly `pure`' which means 'parameters are
values or immutable'. To reduce code breakage, the 'str
On Saturday, 17 July 2021 at 05:44:24 UTC, ag0aep6g wrote:
I tried doing that, but `-preview=dip1000` causes trouble. This
fails:
(...)
I'm not sure what's going on.
I'm not completely caught up, but from what I see, pure and
immutable have a history of issues:
[Issue 11503 - Type system br
On 17.07.21 00:27, H. S. Teoh wrote:
Hmm, OK. Not sure why .array isn't being inferred as unique... but yeah,
you probably have to resort to using @trusted with .assumeUnique.
In addition to `pure`, you also need a const/immutable input and a
mutable output, so that the output cannot be a slic
On 7/16/21 3:21 PM, Dennis wrote:
> But `pure` is no silver bullet:
Agreed. I occasionally struggle with these issues as well. Here is a
related one:
import std;
void foo(const int[] a) {
auto b = a.array;
b.front = 42;
// Error: cannot modify `const` expression `front(b)`
}
I think t
On Fri, Jul 16, 2021 at 10:23:31PM +, Dennis via Digitalmars-d-learn wrote:
> On Friday, 16 July 2021 at 20:45:11 UTC, H. S. Teoh wrote:
> > Have you tried `pure`?
>
> The code in question is all `@safe pure nothrow`.
Hmm, OK. Not sure why .array isn't being inferred as unique... but yeah,
yo
On Friday, 16 July 2021 at 20:45:11 UTC, H. S. Teoh wrote:
Have you tried `pure`?
The code in question is all `@safe pure nothrow`.
On Friday, 16 July 2021 at 20:39:41 UTC, Ali Çehreli wrote:
So to me, newly created data should be mutable for the most
usability.
It's clear that I stripped away too much context with the toy
examples, so let me try to add some back. I don't like forcing
the use of `immutable` in general, bu
On Fri, Jul 16, 2021 at 08:19:32PM +, Dennis via Digitalmars-d-learn wrote:
[...]
> ```D
> immutable(int)[] positive(int[] input) @safe
> {
> return input.filter!(x => x > 0).array;
> }
> ```
[...]
> I could make another primitive (`iarraySort`), but I wonder if there
> are more convenient
On 7/16/21 1:19 PM, Dennis wrote:
> I like passing around immutable data
I think the D community needs to talk more about guidelines around
'immutable'. We don't... And I lack a complete understanding myself. :)
To me, 'immutable' is a demand of the user from the provider that the
data will
I like passing around immutable data, but I don't like creating
it. Here are some toy examples to illustrate:
```D
immutable(int)[] positive(int[] input) @safe
{
return input.filter!(x => x > 0).array;
}
```
Error: cannot implicitly convert expression
`array(filter(input))` of type `int[]`
15 matches
Mail list logo
