On 11/7/10 11:34 PM, spir wrote:
On Sun, 07 Nov 2010 19:12:02 -0600
Andrei Alexandrescu wrote:
On 11/7/10 1:54 PM, retard wrote:
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
Kagamin wrote:
> Adam Burton Wrote:
>
>> The above seems correct to me. You are assigning a nullable to a non-
>> nullable so you force the user to assess that is correct and provide an
>> override. Based on that I've had a crack at this myself.
>
> This becomes not just an annotation, but anoth
On Sunday, November 07, 2010 18:42:08 Adam Burton wrote:
> 1. Default struct constructor.
> This means the NN can be created without assigning a value. I have tried to
> get around this issue somewhat by adding a null check in the invariant but
> it seems the invariant is not called when using the
so Wrote:
> > This way or another, you need a null check. Why extra syntax?
>
> This is also how it is done in those languages no?
> They also have null checks at every assignment, but since compiler puts
> those lines, you don't know anything.
>
> Maybe this is not what you mean?
Do you care
This way or another, you need a null check. Why extra syntax?
This is also how it is done in those languages no?
They also have null checks at every assignment, but since compiler puts
those lines, you don't know anything.
Maybe this is not what you mean?
--
Using Opera's revolutionary emai
On Sun, 07 Nov 2010 18:12:50 -0500
bearophile wrote:
> retard:
>
> > I bet even the basic class/interface/exception system of D is too complex
> > to explain for some members of the audience. You can't assume that the
> > same people who *use* the language can/want to understand the
> > imple
Adam Burton Wrote:
> The above seems correct to me. You are assigning a nullable to a non-
> nullable so you force the user to assess that is correct and provide an
> override. Based on that I've had a crack at this myself.
This becomes not just an annotation, but another type. When you pass arg
On Sun, 07 Nov 2010 19:12:02 -0600
Andrei Alexandrescu wrote:
> On 11/7/10 1:54 PM, retard wrote:
> > 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
>
Adam Burton wrote:
Thoughts up to now? Am I barking up completely the wrong tree?
I think it's a good start on figuring this out.
Kagamin wrote:
> 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)
>
Andrei:
> This thread does have a good outcome: Walter will at least consider
> improving flow analysis in constructors to support @disable'd default
> constructors. That is the key improvement that allows NonNull as a library.
Good :-)
Bye,
bearophile
On 11/7/10 1:54 PM, retard wrote:
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
retard:
> I bet even the basic class/interface/exception system of D is too complex
> to explain for some members of the audience. You can't assume that the
> same people who *use* the language can/want to understand the
> implementation of the features.
You are right. The people that use the
Sun, 07 Nov 2010 17:06:12 -0500, bearophile wrote:
> retard:
>
>> 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.
retard:
> 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.
If a langu
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
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 featur
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
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
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 a
On Sun, 07 Nov 2010 20:21:49 +0300, steveh 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 fea
Simen kjaeraas wrote:
Denis Koroskin <2kor...@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 behav
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()
Denis Koroskin <2kor...@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 su
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
25 matches
Mail list logo
