On Monday, 16 September 2013 at 15:47:36 UTC, ilya-stromberg wrote:
> On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin wrote:
>> On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
>>> All your examples are great, thank you ! Is there a way to omit validate such that the compiler would call it implicitly ?
>>>
>>> For example :
>>>
>>> class C {
>>> ...
>>> }
>>>
>>> void fun(@nonNull C c) {
>>> ...
>>> };
>>>
>>> C c;
>>> fun(c);  //compilation error since C is null
>>
>> No, this isn't doable with UDAs because what you want requires runtime check. It is doable using other language features.
>
> It's intresting how can I check that pointer is not null at the compile time. Can you print a example, please?
> I know that we can use contract programming, but it requires runtime check.

That isn't possible. ;)

On Monday, 16 September 2013 at 16:50:43 UTC, Namespace wrote:
> On Monday, 16 September 2013 at 15:47:36 UTC, ilya-stromberg wrote:
>> On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin wrote:
>>> On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
>>>> All your examples are great, thank you ! Is there a way to omit validate such that the compiler would call it implicitly ?
>>>>
>>>> For example :
>>>>
>>>> class C {
>>>> ...
>>>> }
>>>>
>>>> void fun(@nonNull C c) {
>>>> ...
>>>> };
>>>>
>>>> C c;
>>>> fun(c);  //compilation error since C is null
>>>
>>> No, this isn't doable with UDAs because what you want requires runtime check. It is doable using other language features.
>>
>> It's intresting how can I check that pointer is not null at the compile time. Can you print a example, please?
>> I know that we can use contract programming, but it requires runtime check.
>
> That isn't possible. ;)

Similar effect can be achieved by different way. If some function takes S as parameter, one cannot pass directly instance of A or null - error will be issued which is some sort of compile-time protection.

class A
{	
        int i;
}

struct S
{
    A a;
    A getA()
    {
        if (a is null)
            a = new A;
            return a;
        }
    alias getA this;
}

void main()
{
   S s;
   assert (s.i is 0);
   S ss = S.init;
   assert (ss.i is 0);
}

Unfortunately D does not have non-nullable classes which is a problem #1. Ideally structs should have default constructors (hello to those who miss them - problem #2) which could initialize class instance. Since they are absent, wrapping struct can be enhanced by inserting disabled constructor to ensure that no default struct instances with null references are created. However, since disabled constructors are also flawed (they don't prevent from producing T.init values by design and in some situations dmd is not smart enough to detect other cases by mistake) which is a problem #3, non-null classes can be simulated by code above using alias this + rt check. At least this works with two most problematic cases of struct initilialization: without initializer and with T.init value.

On Monday, 16 September 2013 at 17:50:16 UTC, Maxim Fomin wrote:
> Ideally structs should have default constructors (hello to those who miss them - problem #2) which could initialize class instance.

Do you know why D structs don't have default constructors? I really miss.

On Monday, 16 September 2013 at 17:50:16 UTC, Maxim Fomin wrote:
> On Monday, 16 September 2013 at 16:50:43 UTC, Namespace wrote:
>> On Monday, 16 September 2013 at 15:47:36 UTC, ilya-stromberg wrote:
>>> On Monday, 16 September 2013 at 15:12:05 UTC, Maxim Fomin wrote:
>>>> On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
>>>>> All your examples are great, thank you ! Is there a way to omit validate such that the compiler would call it implicitly ?
>>>>>
>>>>> For example :
>>>>>
>>>>> class C {
>>>>> ...
>>>>> }
>>>>>
>>>>> void fun(@nonNull C c) {
>>>>> ...
>>>>> };
>>>>>
>>>>> C c;
>>>>> fun(c);  //compilation error since C is null
>>>>
>>>> No, this isn't doable with UDAs because what you want requires runtime check. It is doable using other language features.
>>>
>>> It's intresting how can I check that pointer is not null at the compile time. Can you print a example, please?
>>> I know that we can use contract programming, but it requires runtime check.
>>
>> That isn't possible. ;)
>
> Similar effect can be achieved by different way. If some function takes S as parameter, one cannot pass directly instance of A or null - error will be issued which is some sort of compile-time protection.
>
> class A
> {	
>         int i;
> }
>
> struct S
> {
>     A a;
>     A getA()
>     {
>         if (a is null)
>             a = new A;
>             return a;
>         }
>     alias getA this;
> }
>
> void main()
> {
>    S s;
>    assert (s.i is 0);
>    S ss = S.init;
>    assert (ss.i is 0);
> }
>
> Unfortunately D does not have non-nullable classes which is a problem #1. Ideally structs should have default constructors (hello to those who miss them - problem #2) which could initialize class instance. Since they are absent, wrapping struct can be enhanced by inserting disabled constructor to ensure that no default struct instances with null references are created. However, since disabled constructors are also flawed (they don't prevent from producing T.init values by design and in some situations dmd is not smart enough to detect other cases by mistake) which is a problem #3, non-null classes can be simulated by code above using alias this + rt check. At least this works with two most problematic cases of struct initilialization: without initializer and with T.init value.

Yes, I know. Search for my name and not null, you will find many topics.

I hate this NotNull struct hack. It is the same crap as the current scope solution. BTW: I'm curious which built-in feature will be removed next, maybe AA?

An annotation like Foo! f would be much nicer than NotNull!Foo or @NotNull Foo, but it would be an agreement.

And I agree absolute, to disable default CTor's by struct's was a huge mistake. But D is full of those. ;)

On Monday, 16 September 2013 at 18:44:25 UTC, ilya-stromberg wrote:
> On Monday, 16 September 2013 at 17:50:16 UTC, Maxim Fomin wrote:
>> Ideally structs should have default constructors (hello to those who miss them - problem #2) which could initialize class instance.
>
> Do you know why D structs don't have default constructors? I really miss.

My favorites:
http://forum.dlang.org/thread/ij6kl4$2jv9$1@digitalmars.com
http://forum.dlang.org/thread/bvuquzwfykiytdwsqkky@forum.dlang.org
http://forum.dlang.org/thread/icjwbtlxsaekksyoljfp@forum.dlang.org

On Monday, 16 September 2013 at 10:29:12 UTC, matovitch wrote:
> All your examples are great, thank you ! Is there a way to omit validate such that the compiler would call it implicitly ?
>
> For example :
>
> class C {
>   ...
> }
>
> void fun(@nonNull C c) {
>   ...
> };
>
> C c;
> fun(c);  //compilation error since C is null

As others have noted, the compiler cannot know what any of your attributes mean.
But you can do this:

class C {
  invariant() {
    validate(this);
  }
}

On Mon, Sep 16, 2013 at 08:56:17PM +0200, Namespace wrote: [...]
> I hate this NotNull struct hack. It is the same crap as the current scope solution. BTW: I'm curious which built-in feature will be removed next, maybe AA?
[...]

That wouldn't be a bad idea, actually. The current AA implementation is so horribly broken, and so wrong in so many ways (there are at least 75 bugs related to AA's, some of the worst of which are 11037, 11025, 10916, 10525, 10381, 10380, 10046, just to name a few), that it would do a world of good to get rid of them altogether, and then reintroduce a properly-designed library solution for them.

Of course, in the meantime everyone whose code breaks because of that will form a mob to lynch me, so I'll have to survive long enough to get the library solution working first. :-P


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet cooking.

On 9/16/13 11:56 AM, Namespace wrote:
> I hate this NotNull struct hack. It is the same crap as the current
> scope solution.

Scoped variables in the language were a lot worse.

> BTW: I'm curious which built-in feature will be removed
> next, maybe AA?

If we're diligent and lucky, hopefully.

> An annotation like Foo! f would be much nicer than NotNull!Foo or
> @NotNull Foo, but it would be an agreement.

Is annotation the only or main problem?

> And I agree absolute, to disable default CTor's by struct's was a huge
> mistake. But D is full of those. ;)

They are not disabled. It seems many people are having trouble with getting default constructors to evaluate code, so I assume you mean that. One possibility (or first step) would be to relax the language to allow CTFE-executable code in default constructors.


Andrei

On Mon, Sep 16, 2013 at 12:28:21PM -0700, Andrei Alexandrescu wrote:
> On 9/16/13 11:56 AM, Namespace wrote:
> >I hate this NotNull struct hack. It is the same crap as the current scope solution.
> 
> Scoped variables in the language were a lot worse.

One thing I'd *really* like to have is proper escape analysis and inlining of scope delegates. I've been waiting a long time for this, and there are no signs of implementation in sight. :-(


> >BTW: I'm curious which built-in feature will be removed next, maybe AA?
> 
> If we're diligent and lucky, hopefully.

I don't see what luck has to do with it...  Currently, I lack just time and adequate understanding of DMD internals; if I had both, I'd rip out the AA implementation from DMD right now, and replace it with something saner.


[...]
> >And I agree absolute, to disable default CTor's by struct's was a huge mistake. But D is full of those. ;)
> 
> They are not disabled.
[...]

Huh, what?

	struct S {
		this() {}
	}

DMD output:

/tmp/test.d(2): Error: constructor test.S.this default constructor for structs only allowed with @disable and no body


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel

On Monday, 16 September 2013 at 19:28:22 UTC, Andrei Alexandrescu wrote:
> On 9/16/13 11:56 AM, Namespace wrote:
>> And I agree absolute, to disable default CTor's by struct's was a huge
>> mistake. But D is full of those. ;)
>
> They are not disabled. It seems many people are having trouble with getting default constructors to evaluate code, so I assume you mean that. One possibility (or first step) would be to relax the language to allow CTFE-executable code in default constructors.

Yes, we REALLY need this. I know that we can init struct fields via user-defined value, but for many cases is not enough. And in that days I  remembered C++.

Buy the way, what does it mean "They are not disabled"?

struct Foo
{
	int i = 5; //works
}

struct Bar
{
	int i;
	
	this()
	{
		i = 5;
	}
}

DMD:
src/app.d(10): Error: constructor app.Bar.this default constructor for structs only allowed with @disable and no body