On Friday, 24 May 2013 at 13:05:36 UTC, bearophile wrote:
> Max Samukha:
>
>> Note that the Nullable is not phobos Nullable -
>> the latter incurs unnecessary overhead for types that are already nullable.
>
> In Bugzilla I have suggested some improvements for Nullable, but in Phobos there is already an alternative Nullable that avoids that overhead:
>
> struct Nullable(T, T nullValue);
>
> Bye,
> bearophile

The question is what should be the result of:

Nullable(int*)?
Nullable!(Nullable!T)?

Forbidden (like in C#)? Aliased to the source type? A distinct type?

Max Samukha:

> The question is what should be the result of:
>
> Nullable(int*)?
> Nullable!(Nullable!T)?
>
> Forbidden (like in C#)? Aliased to the source type? A distinct type?

In D Nullable!(int*) needs to be a different type, because the interface is different between a pointer and a Nullable.

But often you want to use something like Nullable(int*, null) or Nullable(int*, cast(int*)null) instead.

In the second case maybe it can be collapsed into a single Nullable, but such behavior needs to be documented.

Bye,
bearophile

On Friday, 24 May 2013 at 14:03:24 UTC, bearophile wrote:
> Max Samukha:
>
>> The question is what should be the result of:
>>
>> Nullable(int*)?
>> Nullable!(Nullable!T)?
>>
>> Forbidden (like in C#)? Aliased to the source type? A distinct type?
>
> In D Nullable!(int*) needs to be a different type, because the interface is different between a pointer and a Nullable.

It could be normalized by free functions isNull(T)(T t), nullableValue(T)(..) etc. Isn't that what was done to arrays so they could support the range interface?

>
> But often you want to use something like Nullable(int*, null) or Nullable(int*, cast(int*)null) instead.

Do you have an example? In what cases is the distinction between a null null int* and non-null null int* necessary?

>
> In the second case maybe it can be collapsed into a single Nullable, but such behavior needs to be documented.

Ok.

>
> Bye,
> bearophile

Max Samukha:

> It could be normalized by free functions isNull(T)(T t), nullableValue(T)(..) etc.

In Haskell/Scala if you program idiomatically you usually use HOFs as map, filter, etc that work "transparently" on nullables or collection of nullables, because Maybe is a monad.
Example: you have a range of nullables, and you map a function on it, using a special map that ignores the null items. (This is one of the improvements I have suggested in Bugzilla.)


>> But often you want to use something like Nullable(int*, null) or Nullable(int*, cast(int*)null) instead.
>
> Do you have an example? In what cases is the distinction between a null null int* and non-null null int* necessary?

If you use a Nullable!(int*, null) type that distinction vanishes, there is only one null.

Bye,
bearophile

On Friday, 24 May 2013 at 13:49:14 UTC, Max Samukha wrote:
> On Friday, 24 May 2013 at 13:05:36 UTC, bearophile wrote:
>> Max Samukha:
>>
>>> Note that the Nullable is not phobos Nullable -
>>> the latter incurs unnecessary overhead for types that are already nullable.
>>
>> In Bugzilla I have suggested some improvements for Nullable, but in Phobos there is already an alternative Nullable that avoids that overhead:
>>
>> struct Nullable(T, T nullValue);
>>
>> Bye,
>> bearophile
>
> The question is what should be the result of:
>
> Nullable(int*)?

New type, but no overhead.

> Nullable!(Nullable!T)?
>

New type, with an extra boolean.

On Tuesday, 7 May 2013 at 20:17:43 UTC, QAston wrote:
>> No. A tutorial on memory consistency models would be too long to insert here. I don't know of a good online resource, does anyone?
>>
>> Andrei
>
> This was very helpful for me - focuses much more on the memory model itself than the c++11 part.
>
> http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2

This was awesome/amazing.