is it bug?

[Steven Schveighoffer]

On 9/26/17 3:13 AM, drug wrote:
> 25.09.2017 22:58, Steven Schveighoffer пишет:
>>
>> First up, the non-bug:
>>
>> You wrote:
>>
>> writeln(bar.foo.isNull); // false
>> writeln(bar.foo); // error
>>
>> But bar.foo is this:
>>
>> struct Foo
>> {
>>     Nullable!(char[2]) value;
>> }
>>
>> And bar.foo is nullable itself. It's a nullable!Foo.
>>
>> It's a Nullable!Foo, that is not null, but contains a 
>> Nullable!(char[2]) that *is* null.
>>
>> So when you print Foo, it calls the get on it, which works, and then 
>> tries to print all its members (the default thing for std.format), and 
>> when it gets to the *value* member, it crashes.
> 
> so the bug here is that instead of outputting "null" it tries to get 
> null value, isn't it?

Yes, that is the bug, as I said at the end of my message. But you had 
confused the issue by showing that "hey bar.foo isn't null!" which had 
nothing to do with the bug. It wasn't null, and wasn't improperly being 
treated as null. You don't need Bar at all to show the issue.

> And I guess that std.format process char-based 
> types in different manner than others so we have working int, float etc 
> arrays and failing char-based types (string, wstring, char[], static 
> char[] and so on)

It's not that simple:

Nullable!(char[]) x;
writeln(x); // Nullable.null;
static struct Foo { Nullable!(char[]) x; }
Foo foo;
writeln(foo); // error

So in one context, printing a nullable char[] works exactly as expected. 
In another context it does something different. The place where it's 
different needs to be diagnosed and fixed.

-Steve