Jacob Wujciak-Jens

Maybe im just a bit dumb right now but why would you need two definitions in that case? Addtionaly the "dual" flag would allow for just setting it to TRUE...

Ah that makes sense. I mean we could make defDataAdd use the same code as defData without changeing the external behaviour if you were thinking about that.

For the user? no, but it sounds like you are happy with the way it work at the moment? For us it would reduce the amount of code to maintain.

There was also the idea from you at some point to add a "previous Dataset" parameter to defData. is this still something you are interested in?

Ok, maybe we should than make clear via warning that the id parameter will be ignored if a data definition is supplied (the current behaviour).

> I am thinking to put this on hold - I think I talked myself out of making any changes to this. Any new insights on this? Or do you...

@kgoldfeld That is intended behavior by data.table as I understand. The terminology is pass-by-value vs. pass-by-reference. R almost exclusively works via pass-by-value, which means that arguments to functions are copied...

I can blame you for that 😝 because I just reused the body of `genCorOrdCat` where you don't seem to do the copy thing: https://github.com/kgoldfeld/simstudy/blob/84d995dc0684d7a790633bccf81dad480915ba85/R/generate_correlated_data.R#L622 But what ever the case...

I had a quick look and at the moment many but not all functions copy their input data.table. I would argue for creating one consistent behavior across all simstudy functions,...

ok I will look into it