Thread overview
Encapsulate arguments
Jan 01, 2014
alex burton
Jan 01, 2014
Adam D. Ruppe
Jan 02, 2014
alex burton
Jan 02, 2014
Adam D. Ruppe
Jan 02, 2014
Simen Kjærås
January 01, 2014
struct Init
{
Factory * factory;
Other arg1;
Another arg2;
};

void foo(const Init& init);

void bar(const Init& init)
{
      foo(init);
      other stuff;
};

bar(Init(factory,other args));


In C++ I often wrap some arguments that are common to multiple
functions in a struct.
This idiom can reduce typing when the args change.
It is particularly useful in testable code for constructors and
factory methods.
It adds minimal overhead and is really just syntax.
In D there are no header files to change making it slightly less
useful. In D you dont need to write the trivial ctor for Init
making it easier.

In D this would be void bar(in Init init) which makes init const
making all of the parts of init const. This means this idiom
cannot be applied as often args will be refences to mutable
objects.

Does anyone know an equivalent idiom for D ?
January 01, 2014
On Wednesday, 1 January 2014 at 23:00:33 UTC, alex burton wrote:
> In D this would be void bar(in Init init) which makes init const

You should just take Init, without the in.

"in" means that you won't modify AND that you won't let any reference to the argument escape the function's scope. The second part isn't enforced by the compiler right now, but this may change at some point.

"in" basically is "look, don't keep", and since ctor arguments are often kept in the class, it isn't ideal there.

But plain non-const, non-in structs should be fine, that works the same way as a regular function argument list.
January 02, 2014
On Wednesday, 1 January 2014 at 23:11:49 UTC, Adam D. Ruppe wrote:
> On Wednesday, 1 January 2014 at 23:00:33 UTC, alex burton wrote:
>> In D this would be void bar(in Init init) which makes init const
>
> You should just take Init, without the in.
>
> "in" means that you won't modify AND that you won't let any reference to the argument escape the function's scope. The second part isn't enforced by the compiler right now, but this may change at some point.
>
> "in" basically is "look, don't keep", and since ctor arguments are often kept in the class, it isn't ideal there.
>
> But plain non-const, non-in structs should be fine, that works the same way as a regular function argument list.

Thanks but won't the struct be copied at every function call then ?
January 02, 2014
On Thursday, 2 January 2014 at 01:07:01 UTC, alex burton wrote:
> Thanks but won't the struct be copied at every function call then ?

Yeah (unless the compiler optimizes it out), but that's not a big deal, and might even be better, since the fields need to be loaded anyway and doing it through a pointer might be a waste.

But normal function arguments are copied anyway, so it is no loss.
January 02, 2014
On 2014-01-02 02:44, Adam D. Ruppe wrote:
> On Thursday, 2 January 2014 at 01:07:01 UTC, alex burton wrote:
>> Thanks but won't the struct be copied at every function call then ?
>
> Yeah (unless the compiler optimizes it out), but that's not a big deal,
> and might even be better, since the fields need to be loaded anyway and
> doing it through a pointer might be a waste.
>
> But normal function arguments are copied anyway, so it is no loss.

Also, if copying is problematic, use ref.

--
  Simen