On 2012-11-21 19:11, Namespace wrote:

> Nothing, if enough people say that they need him I will implement them
> again.
> But maybe better. :)

Cool :)

> const in D1 isn't the const as in D2 and enforce only that the object
> cannot be assigned again? Strange. O.o

Yes, it worked a bit more like "const" in C than in C++. I just came to think of this since you mentioned "lazy const".

> But then I will think about it. Schould not be much work.

Thanks.

-- 
/Jacob Carlborg

On 2012-11-21 10:37, Namespace wrote:
> After some consideration, I now have the following things, which I wish
> that D would have them built-in:
>   - scope arrays: like static arrays, but you can init them at runtime
> with constant and non-constant expressions and they are resizeable if
> you have to. They will (so far) allocated on the heap and will released
> at the end of the lifetime of the scope. Furthermore you _can_ reserve
> memory, but by default the length and the capacity of the array are
> equal. Means: you don't pay (by default) for memory which you don't
> need. Syntax idea: 'scope int[5] arr;' and 'scope int[some_runtime_int]
> arr;'
>   - lazy const: Just a spontaneous idea: I have often variables, which
> aren't initialize in the CTor, but they are initialized only once, and
> then they should be constant. That isn't possible yet. Therefore I whish
> something like: lazy const var;
>   - And of course: not-null references. There is not much to say.
> Current syntax idea comes from C++: Foo& f = other_f;
>
> So what do you mean about these ideas? And if you like one, what do you
> mean about the syntax?

A property shortcut syntax would be cool to have.

class Foo
{
    @property int bar;
}

Lowered to:

class
{
    private int bar_;

    @property int bar () { return bar_; }
    @property int bar (int value) { return bar_ = value; }
}

It would also be nice if you could manually implement any of the getter or setter and none would be generated in that case.

-- 
/Jacob Carlborg

> A property shortcut syntax would be cool to have.
>
> class Foo
> {
>     @property int bar;
> }
>
> Lowered to:
>
> class
> {
>     private int bar_;
>
>     @property int bar () { return bar_; }
>     @property int bar (int value) { return bar_ = value; }
> }
>
> It would also be nice if you could manually implement any of the getter or setter and none would be generated in that case.
Hm, I like the Idea.
But I would prefer:
private:
    int _bar in(int val) {
        _bar = val;
    } out {
        return _bar;
    }
which results in:
private:
     int _bar;

     @property int bar() { return _bar_; }
     @property void bar(int val) { _bar = val; }

> It means to try to use your feature(s) to rewrite/modify several of those little programs, and then take at how much frequently you use those new features, what advantages they give you, and so on. An usability experiment.
>
> Bye,
> bearophile

A short question: what ist your imagination of a perfect not-null references? What should they can do, how they should assigned? Only with (valid) lvalues, or even with rvalues? Tell me a bit of your thoughts.

Namespace:

> A short question: what ist your imagination of a perfect not-null references? What should they can do, how they should assigned? Only with (valid) lvalues, or even with rvalues? Tell me a bit of your thoughts.

I put some partial notes here:
http://d.puremagic.com/issues/show_bug.cgi?id=4571

See in particular:
http://research.microsoft.com/pubs/67461/non-null.pdf

Bye,
bearophile

On Wednesday, 21 November 2012 at 23:47:55 UTC, bearophile wrote:
> Namespace:
>
>> A short question: what ist your imagination of a perfect not-null references? What should they can do, how they should assigned? Only with (valid) lvalues, or even with rvalues? Tell me a bit of your thoughts.
>
> I put some partial notes here:
> http://d.puremagic.com/issues/show_bug.cgi?id=4571
>
> See in particular:
> http://research.microsoft.com/pubs/67461/non-null.pdf
>
> Bye,
> bearophile

Thank you. So you would prefer it if they accept ravlues _and_ lvalues. Ok.

On 2012-11-21 21:48, Namespace wrote:

> Hm, I like the Idea.
> But I would prefer:
> private:
>      int _bar in(int val) {
>          _bar = val;
>      } out {
>          return _bar;
>      }

The point was to make the syntax short. I wouldn't consider this much of an improvement.

-- 
/Jacob Carlborg

On Thursday, 22 November 2012 at 07:14:38 UTC, Jacob Carlborg wrote:
> On 2012-11-21 21:48, Namespace wrote:
>
>> Hm, I like the Idea.
>> But I would prefer:
>> private:
>>     int _bar in(int val) {
>>         _bar = val;
>>     } out {
>>         return _bar;
>>     }
>
> The point was to make the syntax short. I wouldn't consider this much of an improvement.

IMO is too short not always the best. Therefore I like the C# syntax with set and get. The aquivalent of this in D is IMO 'in' and 'out'.

On Thursday, 22 November 2012 at 11:55:08 UTC, Namespace wrote:
> On Thursday, 22 November 2012 at 07:14:38 UTC, Jacob Carlborg wrote:
>> On 2012-11-21 21:48, Namespace wrote:
>>
>>> Hm, I like the Idea.
>>> But I would prefer:
>>> private:
>>>    int _bar in(int val) {
>>>        _bar = val;
>>>    } out {
>>>        return _bar;
>>>    }
>>
>> The point was to make the syntax short. I wouldn't consider this much of an improvement.
>
> IMO is too short not always the best. Therefore I like the C# syntax with set and get. The aquivalent of this in D is IMO 'in' and 'out'.

I believe Jacob is referring to C#'s auto-implemented properties: http://msdn.microsoft.com/en-us/library/bb384054.aspx

The compiler generates the get/set pair and backing store from the user's single-line declaration.

So,

   @property int bar();

would expand to:

  private int bar_;

  @property void bar(int value) {
    bar_ = value;
  }

  @property int bar() {
    return bar_;
  }

Oh, I didn't know that, thanks.