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?

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?

Is this in addition to what you had previously or is that removed?

In addition to this, how about "final" variables, or something similar.

final Foo foo = new Foo;

It's not possible to reassign a "final" variable but you can call any method on it, not just const/immutable methods.

-- 
/Jacob Carlborg

It is a completly restart.
Hm, I don't know, a solution for 'final' should be this:
[code]
struct Final(T) {
private:
	T _val;
	
public:
	@disable
	this();
	
	this(T val) {
		this._val = val;
	}
	
	@disable
	ref typeof(this) opAssign(T val);
	
	@property
	inout(T) get() inout {
		return this._val;
	}
	
	alias get this;
}
[/code]
If you can write some use cases for this I will think about it.

Namespace:

>  - scope arrays: like static arrays,

I think they are fully implementable in library code. Maybe
Phobos Array already does that fully.

While Variable Length Arrays allocated on the heap can't be
implemented with a nice syntax in library code, so I think they
are more fit for a built-in implementation (but they need new
syntax and they are more complex to implement).


>  - 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;

This is a quite common need, like when you want to perform a
costly computation only once. Maybe there is even an enhancement
request in Bugzilla.

I understand why this is named "lazy const" but this code is
currently accepted:

void foo(lazy const int x) {}
void main() {}


So to avoid confusion I suggest to give a different name to this
feature. One possibility is to use a new keyword, like a
"monoassignable" :-)

How did you implement this feature? If done well, with a good
enough name, it's even possible to make a pull request in the
main D compiler with just this feature.


>  - And of course: not-null references. There is not much to say. Current syntax idea comes from C++: Foo& f = other_f;

Probably this requires far more design to be done well enough.

I suggest to write/adapt several small programs with your new
features (like from here:
http://rosettacode.org/wiki/Category:D), and to try them to see
how useful they are.

Bye,
bearophile

> While Variable Length Arrays allocated on the heap can't be

I meant stack, sorry.

Bye,
bearophile

On 2012-11-21 15:55, Namespace wrote:
> It is a completly restart.

What happened to the elvis-operator. I though that was one of the best features. I also like scoped/stack allocated classes.

> Hm, I don't know, a solution for 'final' should be this:
> [code]
> struct Final(T) {
> private:
>      T _val;
>
> public:
>      @disable
>      this();
>
>      this(T val) {
>          this._val = val;
>      }
>
>      @disable
>      ref typeof(this) opAssign(T val);
>
>      @property
>      inout(T) get() inout {
>          return this._val;
>      }
>
>      alias get this;
> }
> [/code]
> If you can write some use cases for this I will think about it.

class Foo
{
    final Object x;
    final Object y;

    this (Object x, Object y)
    {
        this.x = x;
        this.y = y;
    }
}

I used this all the time in D1, when "const" worked like that. Now I have to create getters for these variables instead:

class Foo
{
    private Object x_;
    private Object y_;

    this (Object x, Object y)
    {
        this.x = x;
        this.y = y;
    }

    Object x () { return x_; }
    Object y () { return y_; }
}

-- 
/Jacob Carlborg

> I think they are fully implementable in library code. Maybe
> Phobos Array already does that fully.
>
> While Variable Length Arrays allocated on the heap can't be
> implemented with a nice syntax in library code, so I think they
> are more fit for a built-in implementation (but they need new
> syntax and they are more complex to implement).
Hm, I like scope int[i] arr; I will think about it.

> This is a quite common need, like when you want to perform a
> costly computation only once. Maybe there is even an enhancement
> request in Bugzilla.
>
> I understand why this is named "lazy const" but this code is
> currently accepted:
>
> void foo(lazy const int x) {}
> void main() {}
Oh good point, thanks.

> So to avoid confusion I suggest to give a different name to this
> feature. One possibility is to use a new keyword, like a
> "monoassignable" :-)
Then preferably "readonly" or something like this. :D Or just 'mono'.

> How did you implement this feature? If done well, with a good
> enough name, it's even possible to make a pull request in the
> main D compiler with just this feature.
I don't understand. What do you mean with 'how'? I will write a struct and replace 'readonly ...' with an instance of ReadOnly!(...) ...

> Probably this requires far more design to be done well enough.
>
> I suggest to write/adapt several small programs with your new
> features (like from here:
> http://rosettacode.org/wiki/Category:D), and to try them to see
> how useful they are.

What do you mean with 'how useful'?

Namespace:

> I will write a struct and replace 'readonly ...' with an instance of ReadOnly!(...) ...

OK.


> What do you mean with 'how useful'?

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

On Wednesday, 21 November 2012 at 17:43:22 UTC, bearophile wrote:
> Namespace:
>
>> I will write a struct and replace 'readonly ...' with an instance of ReadOnly!(...) ...
>
> OK.
Not good? What would be better? :)
>
>> What do you mean with 'how useful'?
>
> 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

Ok.

> What happened to the elvis-operator. I though that was one of the best features. I also like scoped/stack allocated classes.
Nothing, if enough people say that they need him I will implement them again.
But maybe better. :)

> class Foo
> {
>     final Object x;
>     final Object y;
>
>     this (Object x, Object y)
>     {
>         this.x = x;
>         this.y = y;
>     }
> }
>
> I used this all the time in D1, when "const" worked like that. Now I have to create getters for these variables instead:
>
> class Foo
> {
>     private Object x_;
>     private Object y_;
>
>     this (Object x, Object y)
>     {
>         this.x = x;
>         this.y = y;
>     }
>
>     Object x () { return x_; }
>     Object y () { return y_; }
> }

const in D1 isn't the const as in D2 and enforce only that the object cannot be assigned again? Strange. O.o
But then I will think about it. Schould not be much work.