On Saturday, 15 April 2023 at 21:00:01 UTC, kdevel wrote:
On Saturday, 15 April 2023 at 15:50:18 UTC, Dennis wrote:
[...]
care about the type / mutability of the pointer.
Returning `i`'s address in a long does not trigger the escape
detector:
It doesn't care about the type of pointer, but i
On Saturday, 15 April 2023 at 15:50:18 UTC, Dennis wrote:
[...]
care about the type / mutability of the pointer.
Returning `i`'s address in a long does not trigger the escape
detector:
```
long foo (long s, return ref int i)
{
s = cast (long) &i;
return s;
}
auto bar ()
{
int i;
On Saturday, 15 April 2023 at 14:33:52 UTC, kdevel wrote:
Does that make sense?
Whether it makes sense is subjective, but it is by design. Escape
analysis considers every pointer the same, it doesn't care about
the type / mutability of the pointer. In `@system` / `@trusted`
code, you could
On Saturday, 15 April 2023 at 14:10:57 UTC, Dennis wrote:
[...]
This adds complexity, just to add some 'intermediate' safety
between `@system` and `@safe` in a few cases. It's better to
keep the rules simple and consistent.
Thanks for the answer! While playing around with return ref I
came a
On Saturday, 15 April 2023 at 14:10:57 UTC, Dennis wrote:
This adds complexity, just to add some 'intermediate' safety
between `@system` and `@safe` in a few cases. It's better to
keep the rules simple and consistent.
To quote my past self:
There used to be different rules for lifetime error
On Saturday, 15 April 2023 at 13:20:09 UTC, kdevel wrote:
Under which circumstances is it a mistake to insert the
`return` at the indicated position? If there are none why can't
it be done implicitly (automatically)?
It could be done in the easy example you posted, but generalizing
it is hard
On Saturday, 15 April 2023 at 13:24:52 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 16/04/2023 1:20 AM, kdevel wrote:
On Saturday, 15 April 2023 at 12:45:31 UTC, Richard (Rikki)
Andrew Cattermole wrote:
It was bad analysis by the compiler, which has since been
corrected.
It should have be
On 16/04/2023 1:20 AM, kdevel wrote:
On Saturday, 15 April 2023 at 12:45:31 UTC, Richard (Rikki) Andrew
Cattermole wrote:
It was bad analysis by the compiler, which has since been corrected.
It should have been applied only to @safe code.
But why is the @unsafe programmer now left unprotected
On Saturday, 15 April 2023 at 12:45:31 UTC, Richard (Rikki)
Andrew Cattermole wrote:
It was bad analysis by the compiler, which has since been
corrected.
It should have been applied only to @safe code.
But why is the @unsafe programmer now left unprotected in cases
like this
```
ref int fo
It was bad analysis by the compiler, which has since been corrected.
It should have been applied only to @safe code.
On Friday, 14 April 2023 at 11:18:21 UTC, Dennis wrote:
On Friday, 14 April 2023 at 10:31:58 UTC, kdevel wrote:
But in fact it is returned unless it is `return ref`.
When using `return ref`, `return scope`, `scope` etc., you
should be using the latest compiler and annotate functions you
want
On Friday, 14 April 2023 at 10:31:58 UTC, kdevel wrote:
But in fact it is returned unless it is `return ref`.
When using `return ref`, `return scope`, `scope` etc., you should
be using the latest compiler and annotate functions you want
checked with `@safe`. In previous versions, the compiler
On Friday, 14 April 2023 at 09:42:14 UTC, Bastiaan Veelo wrote:
[...]
Up to dmd v2.100.2 I am warned/get an error during compilation:
```
$ dmd returnref2.d
returnref2.d(3): Deprecation: returning `i` escapes a
reference to parameter `i`
returnref2.d(1):perhaps annotate the parameter wi
On Friday, 14 April 2023 at 00:50:31 UTC, kdevel wrote:
```
ref int foo (ref int i)
{
return i;
}
ref int bar ()
{
int i;
return foo (i);
}
void main ()
{
import std.stdio;
auto i = bar;
i.writeln;
}
```
Up to dmd v2.100.2 I am warned/get an error during compilation:
```
$ d
On Thursday, 13 April 2023 at 22:09:48 UTC, Jacob Shtokolov wrote:
[...]
ref opIndex(string key) return
[...]
Regarding the return ref I found this code of 2019 on my harddisk
which is from or was motivated by a dconf talk:
```
ref int foo (ref int i)
{
return i;
}
ref int bar ()
{
On Thursday, 13 April 2023 at 07:05:10 UTC, Chris Katko wrote:
I'm trying to figure out how to return a reference to something
that may not be a reference type.
```d
@safe:
struct Stats
{
float[string] data;
ref opIndex(string key) return
{
// The `require()` takes care of
On Thursday, 13 April 2023 at 07:05:10 UTC, Chris Katko wrote:
Right now, I'm using pointers which resolves to:
```D
// float* opIndex(string key){...} using pointer
(*s["tacos"])++; // works with pointer, but is strange looking
s["tacos"]++; // preferred syntax or something similar
```
You c
On Thursday, 13 April 2023 at 07:05:10 UTC, Chris Katko wrote:
I'm trying to figure out how to return a reference to something
that may not be a reference type.
```D
struct stats
{
float[string] data=0;
float ref opIndex(string key)
{
return data[key]; // want a ref to a specific element
I'm trying to figure out how to return a reference to something
that may not be a reference type.
```D
struct stats
{
float[string] data=0;
float ref opIndex(string key)
{
return data[key]; // want a ref to a specific element
}
}
void test()
{
stats foo;
auto x = foo.bar(); // returns so
19 matches
Mail list logo