On 1/4/2014 11:20 AM, deadalnix wrote:
> Java do not limit the size of object to 64k, but the number of methods (or
> member, I don't have the spec on my eyes now). No size limit. Java rely on
> runtime checks for null.

Java must have changed that, then.

On Saturday, 4 January 2014 at 20:08:32 UTC, Walter Bright wrote:
> On 1/4/2014 11:20 AM, deadalnix wrote:
>> Java do not limit the size of object to 64k, but the number of methods (or
>> member, I don't have the spec on my eyes now). No size limit. Java rely on
>> runtime checks for null.
>
> Java must have changed that, then.

No, the whole 64k story came from Andrei misinterpreting the java spec. It never was.

On 1/4/2014 11:41 AM, bearophile wrote:
> If you write an IDE in D language you wish to avoid this situation :-)

If you write an IDE in any language, you wish to avoid having bugs in it. I know that non-NULL was popularized by that billion dollar mistake article, but step back a moment.

Non-NULL is really only a particular case of having a type with a constrained set of values. It isn't all that special.

On Saturday, 4 January 2014 at 20:16:29 UTC, Walter Bright wrote:
> On 1/4/2014 11:41 AM, bearophile wrote:
>> If you write an IDE in D language you wish to avoid this situation :-)
>
> If you write an IDE in any language, you wish to avoid having bugs in it. I know that non-NULL was popularized by that billion dollar mistake article, but step back a moment.
>
> Non-NULL is really only a particular case of having a type with a constrained set of values. It isn't all that special.

If you step back one step further, you'll notice that having a nullable type may be desirable for almost anything, not only classes/pointers.

On Sat, Jan 04, 2014 at 11:04:59AM -0800, Walter Bright wrote:
> On 1/4/2014 1:18 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> >I don't disagree, but isn't that just a special case of type constraints? Why limit it arbitrarily to null-values, limiting the range of values is useful for ints and floats too. If you move the constraint check to the function caller you can avoid testing when it isn't needed.
> 
> Yes, the non-NULL thing is just one example of a useful constraint one can put on types.

I still like what Walter said in the past about this issue:

	Making non-nullable pointers is just plugging one hole in a
	cheese grater. -- Walter Bright

:-)

There are many other issues to be addressed in an ideal programming language. Range constraints are but another hole in the cheese grater; there are many others.


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.

On Sat, Jan 04, 2014 at 11:07:37AM -0800, Walter Bright wrote:
> On 1/4/2014 4:51 AM, Peter Alexander wrote:
> >It's worth noting that many languages take a long time before they blossom. It took Ruby 10 years before Rails appeared.
> 
> Many languages have a long history before they burst on the scene. It's much like rock bands. The Beatles labored fruitlessly for years in the salt mines before appearing out of nowhere.

I never trusted in the "hot new emerging trends" thing. Artifacts of quality take time to produce and develop, and bandwagons have a reputation of turning out to be disappointments. That goes for programming languages, and also software in general. What stands the test of time is what has the real value.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.

On 1/4/2014 12:24 PM, deadalnix wrote:
> On Saturday, 4 January 2014 at 20:16:29 UTC, Walter Bright wrote:
>> On 1/4/2014 11:41 AM, bearophile wrote:
>>> If you write an IDE in D language you wish to avoid this situation :-)
>>
>> If you write an IDE in any language, you wish to avoid having bugs in it. I
>> know that non-NULL was popularized by that billion dollar mistake article, but
>> step back a moment.
>>
>> Non-NULL is really only a particular case of having a type with a constrained
>> set of values. It isn't all that special.
>
> If you step back one step further, you'll notice that having a nullable type may
> be desirable for almost anything, not only classes/pointers.

I don't really understand your point. Null is not that special.

For example, you may want a constrained type:

1. a float guaranteed to be not NaN
2. a code point guaranteed to be a valid code point
3. a prime number guaranteed to be a prime number
4. a path+filename guaranteed to be well-formed according to operating system rules
5. an SQL argument guaranteed to not contain an injection attack

The list is endless. Why is null special?

On 1/4/14, Adam D. Ruppe <destructionator@gmail.com> wrote:
> The big thing people have asked for before is
>
> Object foo;
> if(auto obj = checkNull(foo)) {
>     obj == NotNull!Object
> } else {
>    // foo is null
> }
>
> and i haven't figured that out yet...

Here you go:

-----
import std.stdio;

struct NotNull(T) { T obj; }

struct CheckNull(T)
{
    private T _payload;

    auto opCast(X = bool)() { return _payload !is null; }

    @property NotNull!T getNotNull() { return NotNull!T(_payload); }
    alias getNotNull this;
}

CheckNull!T checkNull(T)(T obj)
{
    return CheckNull!T(obj);
}

class C { }

void main()
{
    Object foo;
    if (auto obj = checkNull(foo))
    {
        writeln("foo is not null");
    }
    else
    {
        writeln("foo is null");
    }

    foo = new C;

    if (auto obj = checkNull(foo))
    {
        // note: ":" rather than "==" due to alias this.
        static assert(is(typeof(obj) : NotNull!Object));

        // assignment will work of course (alias this)
        NotNull!Object obj2 = obj;

        writeln("foo is not null");
    }
    else
    {
        writeln("foo is null");
    }
}
-----

On 01/04/2014 09:16 PM, Walter Bright wrote:
>
> Non-NULL is really only a particular case of having a type with a
> constrained set of values. It isn't all that special.

If you allow a crude analogy: Constraining a nullable pointer to be not null is like sending an invitation to your birthday party to all your friends and also Chuck, including a notice that Chuck cannot come. You are defending this practise based on the observation that some birthday parties have a required dress code.

On 01/04/2014 11:24 PM, Timon Gehr wrote:
> You are defending this practise based on the observation that some
> birthday parties have a required dress code.

Agh. *practice*.