Thread overview | |||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 07, 2010 Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
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 Re: Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Koroskin | 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 Re: Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Koroskin | 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 Re: Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen kjaeraas | 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 Re: Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
Posted in reply to steveh | 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 Re: Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
Posted in reply to steveh | > 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 Re: Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | 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 Re: Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen kjaeraas | 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 Re: Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | 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 Re: Can non-nullable references be implemented as a library? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Koroskin | 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
|
Copyright © 1999-2021 by the D Language Foundation