Re: DIP1000
On Friday, 24 June 2022 at 17:53:07 UTC, Loara wrote: Why you should use `scope` here? I probably shouldn't. That is why I asked in the «learn» forum… A `scope` pointer variable may refer to a stack allocated object that may be destroyed once the function returns. The objects are in the calling function, not in the connect() function. So they are not destroyed when the connect() function returns. Since a linked list should not contain pointers to stack allocated data you should avoid entirely the `scope` attribute and use instead `const`. It was only an example. There is nothing wrong with connecting objects on the stack.
Re: DIP1000
On Thursday, 23 June 2022 at 16:08:01 UTC, Ola Fosheim Grøstad
wrote:
How am I supposed to write this:
```d
import std;
@safe:
struct node {
node* next;
}
auto connect(scope node* a, scope node* b)
{
a.next = b;
}
void main()
{
node x;
node y;
connect(,);
}
```
Error: scope variable `b` assigned to non-scope `(*a).next`
Why you should use `scope` here? A `scope` pointer variable may
refer to a stack allocated object that may be destroyed once the
function returns.
Since a linked list should not contain pointers to stack
allocated data you should avoid entirely the `scope` attribute
and use instead `const`.
Re: How to use templates in a separate library?
On Thursday, 23 June 2022 at 23:50:42 UTC, monkyyy wrote: On Thursday, 23 June 2022 at 08:12:32 UTC, CrazyMan wrote: linking make sure you use the -i flag when compiling But note, that would be the opposite of using a library.
Re: DIP1000
On Friday, 24 June 2022 at 09:08:25 UTC, Dukc wrote: On Friday, 24 June 2022 at 05:11:13 UTC, Ola Fosheim Grøstad wrote: No, the lifetime is the same if there is no destructor. Being counter intuitive is poor usability. It depends on whether you expect the rules to be smart or simple. Smart is not necessarily better, as the Unix philosophy tells you. I'm sure you have experience about programs that are unpredictable and thus frustating to use because they try to be too smart. If this feature is meant to be used by application developers and not only library authors then it has to match their intuitive mental model of life times. I would expect all simple value types to have the same lifetime as the scope. The other option is to somehow instill a mental model in all users that simple types like ints also having default destructors. If it only is for library authors, then it is ok to deviate from "intuition".
Re: DIP1000
On Friday, 24 June 2022 at 05:11:13 UTC, Ola Fosheim Grøstad wrote: No, the lifetime is the same if there is no destructor. Being counter intuitive is poor usability. It depends on whether you expect the rules to be smart or simple. Smart is not necessarily better, as the Unix philosophy tells you. I'm sure you have experience about programs that are unpredictable and thus frustating to use because they try to be too smart.
Re: int | missing | absent
On Thursday, 23 June 2022 at 15:20:02 UTC, Jesse Phillips wrote: On Wednesday, 22 June 2022 at 01:09:22 UTC, Steven Schveighoffer wrote: There are 3 situations: 1. field in json and struct. Obvious result. 2. field in json but not in struct. 3. field in struct but not in json. I do a lot of reading JSON data in C#, and I heavily lean on optional over required. The reason optional is so beneficial is because I'm looking to pull out specific data points from the JSON, I have no use nor care about any other field. If I had to specify every field being provided, every time something changes, the JSON parser would be completely unusable for me. I do like the @extra assuming it allows reserializing the entire JSON object. But many times that data just isn't needed and I'd like my type to trim it. I'm in a similar boat as you, except for that I read a lot of big json files and I absolutely cannot read everything in the json and hold them in memory, so I must be selective in what I read from the json files, since they're read on a server and are several GB. I would be wasting a lot of RAM resources by having every field in the json file stored in memory. RAM is expensive, disk space is not.
