digitalmars.D - Re: D's greatest mistakes
- Kagamin <spam here.lot> Nov 29 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Nov 29 2010
- Bruno Medeiros <brunodomedeiros+spam com.gmail> Dec 09 2010
- Bruno Medeiros <brunodomedeiros+spam com.gmail> Dec 10 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Dec 09 2010
- "Steven Schveighoffer" <schveiguy yahoo.com> Dec 10 2010
Steven Schveighoffer Wrote:My favorite in recent times is: tail const(C) tailconst;
Tail const is a type constructor, but I don't think that annotations should evolve that far.
Nov 29 2010
On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin <spam here.lot> wrote:Steven Schveighoffer Wrote:My favorite in recent times is: tail const(C) tailconst;
Tail const is a type constructor, but I don't think that annotations should evolve that far.
What I liked about that is it is orthogonal to the constancy. That is, with one annotation you get tail-const, tail-immutable, and tail-shared. It's certainly possible to introduce three new type constructors. -Steve
Nov 29 2010
On 29/11/2010 21:13, Steven Schveighoffer wrote:On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin <spam here.lot> wrote:Steven Schveighoffer Wrote:My favorite in recent times is: tail const(C) tailconst;
Tail const is a type constructor, but I don't think that annotations should evolve that far.
What I liked about that is it is orthogonal to the constancy. That is, with one annotation you get tail-const, tail-immutable, and tail-shared.
By saying that tail is a type constructor, do you mean it can be applied to any const/immutable, anywhere they appear? Like, how do you declare a class var to be head-const and tail-immutable? Or an array of tail-const classes? -- Bruno Medeiros - Software Engineer
Dec 09 2010
On 09/12/2010 18:12, Steven Schveighoffer wrote:On Thu, 09 Dec 2010 12:01:47 -0500, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:On 29/11/2010 21:13, Steven Schveighoffer wrote:On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin <spam here.lot> wrote:Steven Schveighoffer Wrote:My favorite in recent times is: tail const(C) tailconst;
Tail const is a type constructor, but I don't think that annotations should evolve that far.
What I liked about that is it is orthogonal to the constancy. That is, with one annotation you get tail-const, tail-immutable, and tail-shared.
By saying that tail is a type constructor, do you mean it can be applied to any const/immutable, anywhere they appear? Like, how do you declare a class var to be head-const and tail-immutable?
tail immutable(const(T))Or an array of tail-const classes?
tail const(C)[] The tail only applies to the modifier, not to the rest of it. It modifies const.
Ok, what about a head-const array of tail-immutable classes? And would this be allowed: Foo!( tail const(C)) ?BTW, this idea was shown to be too complex for use because of two things: 1. the prospect of having to define both const and tail const member functions is way too complex for normal people, and 2. member functions *always* pass the 'this' pointer by reference on a struct, so you couldn't call for instance an immutable function on a tail-immutable type. -Steve
I was commenting on the syntax aspect only (because it actually seems quite bad to me, not very orthogonal). And both issues above would apply to any tailconst syntax, because they are really about tailconst itself. -- Bruno Medeiros - Software Engineer
Dec 10 2010
On Thu, 09 Dec 2010 12:01:47 -0500, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:On 29/11/2010 21:13, Steven Schveighoffer wrote:On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin <spam here.lot> wrote:Steven Schveighoffer Wrote:My favorite in recent times is: tail const(C) tailconst;
Tail const is a type constructor, but I don't think that annotations should evolve that far.
What I liked about that is it is orthogonal to the constancy. That is, with one annotation you get tail-const, tail-immutable, and tail-shared.
By saying that tail is a type constructor, do you mean it can be applied to any const/immutable, anywhere they appear? Like, how do you declare a class var to be head-const and tail-immutable?
tail immutable(const(T))Or an array of tail-const classes?
tail const(C)[] The tail only applies to the modifier, not to the rest of it. It modifies const. BTW, this idea was shown to be too complex for use because of two things: 1. the prospect of having to define both const and tail const member functions is way too complex for normal people, and 2. member functions *always* pass the 'this' pointer by reference on a struct, so you couldn't call for instance an immutable function on a tail-immutable type. -Steve
Dec 09 2010
On Fri, 10 Dec 2010 13:00:01 -0500, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:On 09/12/2010 18:12, Steven Schveighoffer wrote:On Thu, 09 Dec 2010 12:01:47 -0500, Bruno Medeiros <brunodomedeiros+spam com.gmail> wrote:On 29/11/2010 21:13, Steven Schveighoffer wrote:On Mon, 29 Nov 2010 15:55:10 -0500, Kagamin <spam here.lot> wrote:Steven Schveighoffer Wrote:My favorite in recent times is: tail const(C) tailconst;
Tail const is a type constructor, but I don't think that annotations should evolve that far.
What I liked about that is it is orthogonal to the constancy. That is, with one annotation you get tail-const, tail-immutable, and tail-shared.
By saying that tail is a type constructor, do you mean it can be applied to any const/immutable, anywhere they appear? Like, how do you declare a class var to be head-const and tail-immutable?
tail immutable(const(T))Or an array of tail-const classes?
tail const(C)[] The tail only applies to the modifier, not to the rest of it. It modifies const.
Ok, what about a head-const array of tail-immutable classes?
const( tail immutable(T)[])And would this be allowed: Foo!( tail const(C)) ?
Yes.BTW, this idea was shown to be too complex for use because of two things: 1. the prospect of having to define both const and tail const member functions is way too complex for normal people, and 2. member functions *always* pass the 'this' pointer by reference on a struct, so you couldn't call for instance an immutable function on a tail-immutable type. -Steve
I was commenting on the syntax aspect only (because it actually seems quite bad to me, not very orthogonal). And both issues above would apply to any tailconst syntax, because they are really about tailconst itself.
Any tailconst system that allows applying tail-const to a non-reference type has the issues I mentioned. That is why I'm not advocating for it anymore (gerically applicable tail-const that is). I now think we need: 1. a syntax to make class references tail-const. Michel Fortin has done this. 2. the ability to define implicit casting relationships between types that differ only on constancy. That should give us the ability to define understandable types that can make defining custom constructs that enjoy the same tail-const benefits as builtin arrays. -Steve
Dec 10 2010