Re: @safe question

2022-01-11 Thread Paul Backus via Digitalmars-d-learn
On Wednesday, 12 January 2022 at 00:45:23 UTC, H. S. Teoh wrote: IMNSHO, that @trusted lambda thing is an anti-pattern that should be avoided, needless to say already promoted. It's papering over a problem that ought to be fixed instead of being pushed under the rug. There's nothing wrong

Re: @safe question

2022-01-11 Thread H. S. Teoh via Digitalmars-d-learn
On Wed, Jan 12, 2022 at 12:24:14AM +, forkit via Digitalmars-d-learn wrote: > On Tuesday, 11 January 2022 at 21:50:00 UTC, Paul Backus wrote: > > .. > > If you know a particular bit of code is memory safe, but the compiler > > can't prove it, you can mark that code as @trusted. For example: >

Re: @safe question

2022-01-11 Thread forkit via Digitalmars-d-learn
On Tuesday, 11 January 2022 at 21:50:00 UTC, Paul Backus wrote: .. If you know a particular bit of code is memory safe, but the compiler can't prove it, you can mark that code as @trusted. For example: () @trusted { pointers ~= )(); This example uses an immediately-invoked function

Re: @safe question

2022-01-11 Thread Paul Backus via Digitalmars-d-learn
On Tuesday, 11 January 2022 at 21:38:58 UTC, forkit wrote: On Tuesday, 11 January 2022 at 14:54:51 UTC, Paul Backus wrote: .. If you compile with -preview=dip1000, the compiler will actually keep track of which pointers point to stack memory, and will allow your original code. But

Re: @safe question

2022-01-11 Thread forkit via Digitalmars-d-learn
On Tuesday, 11 January 2022 at 14:54:51 UTC, Paul Backus wrote: .. If you compile with -preview=dip1000, the compiler will actually keep track of which pointers point to stack memory, and will allow your original code. But -preview=dip1000 is still somewhat experimental, and the documentation

Re: @safe question

2022-01-11 Thread Paul Backus via Digitalmars-d-learn
On Tuesday, 11 January 2022 at 10:57:28 UTC, forkit wrote: On Monday, 10 January 2022 at 03:21:46 UTC, Paul Backus wrote: Taking the address of a local variable is forbidden in @safe code. Even though str is a ref variable that points to a heap-allocated string, it is still considered a

Re: @safe question

2022-01-11 Thread forkit via Digitalmars-d-learn
On Monday, 10 January 2022 at 03:21:46 UTC, Paul Backus wrote: Taking the address of a local variable is forbidden in @safe code. Even though str is a ref variable that points to a heap-allocated string, it is still considered a local variable because it is declared inside the body of a

Re: @safe question

2022-01-09 Thread Paul Backus via Digitalmars-d-learn
On Monday, 10 January 2022 at 01:16:31 UTC, forkit wrote: On Sunday, 9 January 2022 at 21:56:05 UTC, Salih Dincer wrote: Try the @trusted and in/out: ... .. . thanks for introducing me to the in/out feature of D :-) I'll certainly look into that feature more. But my question still remains:

Re: @safe question

2022-01-09 Thread forkit via Digitalmars-d-learn
On Sunday, 9 January 2022 at 21:56:05 UTC, Salih Dincer wrote: Try the @trusted and in/out: ... .. . thanks for introducing me to the in/out feature of D :-) I'll certainly look into that feature more. But my question still remains: //pointers ~= // why is this *not* allowed in @safe

Re: @safe question

2022-01-09 Thread Salih Dincer via Digitalmars-d-learn
On Sunday, 9 January 2022 at 20:58:05 UTC, forkit wrote: Do not understand why one line is not considered @safe, but the other is. // module test; import std; @safe void main() { immutable string[] strings = ["one", "one", "two"]; immutable(string)*[] pointers = null;