Jump to page: 1 2 3
Thread overview
Can non-nullable references be implemented as a library?
Nov 07, 2010
Denis Koroskin
Nov 07, 2010
Simen kjaeraas
Nov 07, 2010
Simen kjaeraas
Nov 07, 2010
Kagamin
Nov 08, 2010
Adam Burton
Nov 08, 2010
Walter Bright
Nov 08, 2010
Kagamin
Nov 08, 2010
so
Nov 08, 2010
Kagamin
Nov 08, 2010
Adam Burton
Nov 08, 2010
Jonathan M Davis
Nov 07, 2010
steveh
Nov 07, 2010
Denis Koroskin
Nov 07, 2010
so
Nov 07, 2010
bearophile
Nov 07, 2010
retard
Nov 07, 2010
bearophile
Nov 07, 2010
retard
Nov 07, 2010
bearophile
Nov 08, 2010
spir
Nov 08, 2010
bearophile
Nov 08, 2010
spir
November 07, 2010
Since many people think that non-nullable references can be implemented as a library and thus don't belong to core language, I've decided to show that it is in fact impossible to do so.

How do you enforce the following behavior:

class Foo
{
    this()
    {
	// error: variable nonNull not initialized
    }

    this()
    {
        nonNull.someMethod(); // error: variable used before initialized
        auto s = toString(); // error: can't call any methods before initialized

        nonNull = new Bar();
        s = toString(); // okay
    }

    string toString() { return nonNull.toString(); }

    NonNull!(Bar) nonNull;
}

class Bar : Foo
{
    this()
    {
        nonNull.someMethod(); // error: variable used before initialized

        super(); // initializes nonNull
        nonNull.someMethod(); // fine
    }
}

Without support of these use-cases NonNull!(T) is useless.

There can be other examples, but I think these are enough to prove that non-nullable references can not be implemented in library.
November 07, 2010
Denis Koroskin <2korden@gmail.com> wrote:

> Since many people think that non-nullable references can be implemented as a library and thus don't belong to core language, I've decided to show that it is in fact impossible to do so.
>
> How do you enforce the following behavior:
[snip]
>
> Without support of these use-cases NonNull!(T) is useless.
>
> There can be other examples, but I think these are enough to prove that non-nullable references can not be implemented in library.

Indeed. There is also the arrays I've mentioned before, and as you
mention here, fields of classes and structs. Good catch.

-- 
Simen
November 07, 2010
Denis Koroskin Wrote:

> Since many people think that non-nullable references can be implemented as a library and thus don't belong to core language, I've decided to show that it is in fact impossible to do so.
> 
> How do you enforce the following behavior:
> 
> class Foo
> {
>      this()
>      {
> 	// error: variable nonNull not initialized
>      }
> 
>      this()
>      {
>          nonNull.someMethod(); // error: variable used before initialized
>          auto s = toString(); // error: can't call any methods before
> initialized
> 
>          nonNull = new Bar();
>          s = toString(); // okay
>      }
> 
>      string toString() { return nonNull.toString(); }
> 
>      NonNull!(Bar) nonNull;
> }
> 
> class Bar : Foo
> {
>      this()
>      {
>          nonNull.someMethod(); // error: variable used before initialized
> 
>          super(); // initializes nonNull
>          nonNull.someMethod(); // fine
>      }
> }
> 
> Without support of these use-cases NonNull!(T) is useless.
> 
> There can be other examples, but I think these are enough to prove that non-nullable references can not be implemented in library.

Andrei's stance is, either a library addon or ship D without that feature. D's library already contains both tuples and algebraic data types. They're simple to use, almost like in Python. The reason for library addons isn't that builtin features make less sense, the reason is that TDPL is already out and we can't improve the language in any radical way.
November 07, 2010
Simen kjaeraas <simen.kjaras@gmail.com> wrote:

> Denis Koroskin <2korden@gmail.com> wrote:
>
>> Since many people think that non-nullable references can be implemented as a library and thus don't belong to core language, I've decided to show that it is in fact impossible to do so.
>>
>> How do you enforce the following behavior:
> [snip]
>>
>> Without support of these use-cases NonNull!(T) is useless.
>>
>> There can be other examples, but I think these are enough to prove that non-nullable references can not be implemented in library.
>
> Indeed. There is also the arrays I've mentioned before, and as you
> mention here, fields of classes and structs. Good catch.

Worth adding:
Even if non-null references/pointers cannot be perfectly implemented in a
library, they may still be a worthwhile addition to Phobos, to mark
function arguments and the like.

-- 
Simen
November 07, 2010
On Sun, 07 Nov 2010 20:21:49 +0300, steveh <steveh57@useshotmai.l> wrote:

> Andrei's stance is, either a library addon or ship D without that feature. D's library already contains both tuples and algebraic data types. They're simple to use, almost like in Python. The reason for library addons isn't that builtin features make less sense, the reason is that TDPL is already out and we can't improve the language in any radical way.

People have proposed syntax that won't break existing code (e.g. T@ vs T). It also means T is still nullable by default, and that's good enough for me. Better than nothing anyway.

In addition, I really hope there will be TDPL 2nd edition some day.
November 07, 2010
> Andrei's stance is, either a library addon or ship D without that feature. D's library already contains both tuples and algebraic data types. They're simple to use, almost like in Python. The reason for library addons isn't that builtin features make less sense, the reason is that TDPL is already out and we can't improve the language in any radical way.

Lets talk about solution in this thread more than politics, politics "never" improve anything.
Also It is not only Andrei, every single people here agreed on stopping "lets add this new feature to D today".

For the topic, i am trying to understand the use cases and implementations in other languages first.
D was born to solve problems right?
If supporting a feature looks/is impossible for user we should improve the language to help us solve this not just add the specific feature.
You know there'll never be enough features :)

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
November 07, 2010
so:

> Also It is not only Andrei, every single people here agreed on stopping "lets add this new feature to D today".

What's stopped is adding features to D2, but I have meant nonull types for D3. I don't think D evolution is finished right now. On the other hand new features add complexity, so they may refused in many cases (there are several other things that may be added to D3, like macros, pattern matching, integral overflows, ranged integrals, etc. But some such features add a lot of complexity to a language that's not simple already).


> If supporting a feature looks/is impossible for user we should improve the
> language to help us solve this not just add the specific feature.
> You know there'll never be enough features :)

Are you saying that D may be improved to allow defining good enough nonnull types in user code? This is possible, but it's very hard. It requires macros and a powerful type system that's probably beyond what D will ever hope to have, because maybe not even CommonLips macros are enough for this (and even if such changes will be implemented, the resulting language will be harde to use as ATS or more, I don't think lot of people here will be happy with it). So to not increase the language complexity too much, some features need to be implemented at front-end level. It's a matter of trade-offs.

Bye,
bearophile
November 07, 2010
Simen kjaeraas Wrote:

> Worth adding:
> Even if non-null references/pointers cannot be perfectly implemented in a
> library, they may still be a worthwhile addition to Phobos, to mark
> function arguments and the like.

Hmm... this doesn't work:

struct NonNull(T)
{
	T value;
	this(T v)
	{
		assert(value);
		value=v;
	}
}

class A {}

void foo(NonNull!A a){}

void goo()
{
	A a=new A();
	foo(a);
}

test.d(23): Error: function test.foo (NonNull!(A) a) is not callable using argument types (A)
test.d(23): Error: cannot implicitly convert expression (a) of type test.A to NonNull!(A)
November 07, 2010
Sun, 07 Nov 2010 19:39:09 +0200, so wrote:

>> Andrei's stance is, either a library addon or ship D without that feature. D's library already contains both tuples and algebraic data types. They're simple to use, almost like in Python. The reason for library addons isn't that builtin features make less sense, the reason is that TDPL is already out and we can't improve the language in any radical way.
> 
> Lets talk about solution in this thread more than politics, politics "never" improve anything.

There was this other thread here -- "why a part of d community do not want to go to d2?"

One reason is, there's no good process for handling these feature proposals. Walter attends useless bikeshed discussions and spreads misinformation about things he doesn't get, Andrei has excellent knowledge of languages but he often prefers staying in the background.

There are these DIPs in wiki4d. Were they useful? At least it seems that this thread is leading nowhere. Half of the people don't know what non- nullable means. It's hard to trust this process when it seems to go nowhere. No one wants to validate the design decisions.
November 07, 2010
On 11/7/10 11:13 AM, Denis Koroskin wrote:
> Since many people think that non-nullable references can be implemented
> as a library and thus don't belong to core language, I've decided to
> show that it is in fact impossible to do so.

Changes are necessary to constructors.

Andrei
« First   ‹ Prev
1 2 3