November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | 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? |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | 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 |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | 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 |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > While Variable Length Arrays allocated on the heap can't be
I meant stack, sorry.
Bye,
bearophile
|
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | 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 |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > 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'? |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | 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 |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. |
November 21, 2012 Re: Remus | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | > 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. |
Copyright © 1999-2021 by the D Language Foundation