Optional parameters?

[Jonathan M Davis]

On Sunday, April 01, 2018 11:54:16 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> I currently have a situation where I want to have a function that
> accepts a parameter optionally.
>
> I thought maybe Nullable!int might work:
>
> void foo(Nullable!int) {}
>
> void main()
> {
>     foo(1); // error
>     int x;
>     foo(x); // error
> }
>
> Apparently, I have to manually wrap an int to get it to pass. In other
> languages that support optional types, I can do such things, and it
> works without issues.
>
> I know I can do things like this:
>
> void foo(int x) { return foo(nullable(x)); }
>
> But I'd rather avoid such things if possible. Is there a way around
> this? Seems rather limiting that I can do:
>
> Nullable!int x = 1;
>
> but I can't implicitly convert 1 to a Nullable!int for function calls.

You'll have to call nullable. D has no form of implicit construction. You
can use alias this to define how to convert _from_ a type but not _to_ a
type, and alias this is the only way to define implicit conversions in D. I
think that it works with variable initialization, because on some level, the
compiler treats

Type a = args;

the same as

auto a = Type(args);

e.g.

struct S
{
    int _i;

    this(int i)
    {
        _i = i;
    }
}

void main()
{
    S s = 42;
}

compiles with no alias this at all. Curiously though, if you remove the
explicit constructor, it doesn't compile, even though

auto s = S(42);

would still compile.

Another area where this behavior can be annoying is when returning from a
function call. e.g. this won't compile:

Nullable!int foo(int i)
{
    if(i != 42)
        return i;
    return Nullable!int.init;
}

i needs to be wrapped in a call to nullable or to Nullable!int's constructor
in order for it to compile.

As I understand it, the lack of ability to define implicit construction is
part of the attempt to avoid some of the problems with regards to stuff like
function hijacking that come in C++ from allowing all of the implicit
conversions that it allows. It may also be in part to prevent issues related
to being able to define the same implicit conversion multiple ways (e.g. if
type A implictly casts to B, and you can implicitly construct B from A,
which conversion does the compiler use when converting A to B?).

Ultimately, it's a bit of a double-edged sword in that it prevents certain
classes of bugs but also makes it impossible to do something like have a
function parameter be a wrapper type while the function argument is the type
being wrapped. So, you couldn't do something like use string for IP
addresses everywhere in your code and then change it to a struct later, and
have all of the function calls that passed strings still work without
updating them (which you can do in C++).

Given how problematic implicit conversions tend to be in generic code, I
often think that we might be better off with no user-defined implicit
conversions in D at all, but Nullable is one case where the fact that we
can't define implicit construction gets annoying.

- Jonathan M Davis