On Sunday, 1 April 2018 at 22:44:45 UTC, Jonathan M Davis wrote:
> Which doesn't work in @safe code and doesn't work when you have an rvalue as you would when passing 42. Ultimately, using pointers ultimately either requires explicitly allocating stuff on the heap to be able to pass rvalues, or it has the same restrictions that ref does in terms of passing rvalues. You can certainly take that approach if you'd like, but overall, I think that it's safe to say that using Nullable generally causes fewer problems.

1). There's nothing wrong with @trusted.
2). Rvalue it trivially converted to lvalue on the stack using local variable.
3). You haven't shown syntax for passing null. Pointer is foo(null). Yours will probably be foo(nullable!int());
4). I certanly wouldn't like typing nullable(...) for each optional parameter, I see it as a much bigger problem.

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote:
> I currently have a situation where I want to have a function that accepts a parameter optionally.

why not simply use function overloading?

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer 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.
>
> -Steve

I don't know if this helps but when I hit this situation I usually resort to templates, e.g.

---
void foo(T)(T val = Nullable!int()) if(is(T : int) || is(T == Nullable!int))
{
  writeln(val);
}

void main()
{
   foo(1); // prints: 1
   int x;
   foo(x); // prints: 0
   auto val = Nullable!int(5);
   foo(val); // prints: 5
   foo(); // prints: Nullable.null
}
---

Cheers,
Norm

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer 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
> }


Can somebody enlighten me what this topic is about?

I thought an optional parameter would be as easy as

    void foo(int i = 0) { writeln(i); }

    void main()
    {
        int x;
        foo(x);
        foo(1);
        foo();
    }

Is the Nullable!int approach because 'i' would always "optionally" be 0 if not passed with above 'foo'?

On Monday, 2 April 2018 at 09:31:35 UTC, Timoses wrote:
> On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer 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
>> }
>
>
> Can somebody enlighten me what this topic is about?
>
> I thought an optional parameter would be as easy as
>
>     void foo(int i = 0) { writeln(i); }
>
>     void main()
>     {
>         int x;
>         foo(x);
>         foo(1);
>         foo();
>     }
>
> Is the Nullable!int approach because 'i' would always "optionally" be 0 if not passed with above 'foo'?

Same feeling here, this situation really asks for a Null Object pattern, not nullable. It's sad that nullable isn't very good in that situation but trying to force it in place doesn't seem very reasonnable.

On 4/2/18 5:31 AM, Timoses wrote:
> On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer 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
>> }
> 
> 
> Can somebody enlighten me what this topic is about?
> 
> I thought an optional parameter would be as easy as
> 
>      void foo(int i = 0) { writeln(i); }
> 
>      void main()
>      {
>          int x;
>          foo(x);
>          foo(1);
>          foo();
>      }
> 
> Is the Nullable!int approach because 'i' would always "optionally" be 0 if not passed with above 'foo'?

I'm talking about optionals as they are in other languages, such as Swift: https://en.wikipedia.org/wiki/Option_type

In other words, there is a distinct state of "not provided" from the other values it might take.

Nullable works to fill this purpose, but I didn't realize that I'd have to wrap all calls to it. I was hoping for something more like Swift's option types. In Swift, I would do:

function foo(x: Int?)

And I can check x to see if it's nil inside the function. I can just call foo with a plain Int and it works fine. Int implicitly casts to Int?, but Int? needs an explicit conversion to Int. That was the relationship I was looking for. Apparently, not attainable in D, unless you do it on initialization.

-Steve

On 4/1/18 12:00 PM, Jacob Carlborg wrote:

> 
> Yeah, D doesn't allow user defined implicit conversions, which I think is required for this. I would make function overloading even more complex than it is today.
> 
> Although it would be really handy for cases like this.
> 

Not necessarily implicit conversion, but implicit construction.

The nicety with D's overloading rules are they are simple -- if there is an exact match, use it. If there is a conversion possible, use it. If multiple conversions are possible, ambiguity error.

Adding another way to convert doesn't seem like it would cause lot's of complication or harm.

-Steve

On 4/1/18 6:01 PM, Jonathan M Davis wrote:
> 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.

This is my main reason for confusion -- it should work in all cases, not just this one.

> 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?).

This isn't that hard. You just define an order (obvious choice here is that implicit conversions win over construction).

> 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++).

I'd be fine with a built-in option type, but we have delegated that to the library. But the library isn't up to the (complete) task. It makes things less pleasant, as it exposes a bit of internal implementation for the caller. While I get annoyed quite a bit with Swift's usage of optionals everywhere, they can make dealing with optional data much more concise and straightforward.

> 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.

I agree, they can be annoying. Sometimes you just want to write:

a = b;

and not worry about all the trouble this can cause. Phobos is littered with stuff like hasElaborateCopyConstructor, etc. But it's annoying that we still have to worry about it *and* we can't get all the benefits of having full-blown implicit conversion.

-Steve

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote:
> I currently have a situation where I want to have a function that accepts a parameter optionally.

This is what function overloading and/or default values are for, right?

On Wednesday, 4 April 2018 at 08:08:40 UTC, Dejan Lekic wrote:
> On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote:
>> I currently have a situation where I want to have a function that accepts a parameter optionally.
>
> This is what function overloading and/or default values are for, right?

Not if you'd like to pass an actual _optional_ parameter for e.g. an int.
Default parameter would actually assign a value.

See also:
https://forum.dlang.org/post/rzgcenuqiokknpsltlld@forum.dlang.org