digitalmars.D - How about a special null template parameter?
- Engine Machine (36/36) Aug 19 2016 So we can create types relationships easier:
- Jack Applegame (3/15) Aug 19 2016 What are you talking about? This code doesn't compile. Because
- Engine Machine (5/23) Aug 19 2016 It doesn't matter. That is just a defect of D/language.
- Lodovico Giaretta (37/74) Aug 19 2016 1) `null` has a very precise meaning: it is the only valid value
- Engine Machine (19/113) Aug 19 2016 null as many interpretations. It is ok to expand the meaning. It
- Lodovico Giaretta (26/64) Aug 19 2016 The problem is that null is a valid value to instantiate an alias
- Engine Machine (106/174) Aug 19 2016 Yes, but in this case it is used in a very specific and exact
- Chris Wright (20/23) Aug 19 2016 No. You must weigh the added complexity against the benefits. The less
- Timon Gehr (11/17) Aug 19 2016 alias Seq(T...)=T;
- Engine Machine (57/76) Aug 19 2016 This is a bit verbose and not quite right (T is Dog should be
- Timon Gehr (7/46) Aug 20 2016 Apart from the workaround for the ridiculous alias template parameter
- Engine Machine (50/105) Aug 20 2016 Yes, it is not too bad. One doesn't need to T.length part so it
- Timon Gehr (6/65) Aug 20 2016 I see what you are after (but this was not part of the original
- Engine Machine (22/103) Aug 21 2016 Well, I see that a template with 0 parameters can act as a
- Meta (5/14) Aug 22 2016 I think this is a very bad idea theory-wise, if not in practice
- Engine Machine (11/30) Aug 22 2016 Yeah, maybe... but I think this is a user issue and not a
- Enamex (13/29) Aug 19 2016 Something like this:
- Engine Machine (3/17) Aug 19 2016 How is this any different, besides adding meaningless complexity,
- Enamex (3/26) Aug 19 2016 Um, not sure what you mean. This isn't suggesting adding
- poliklosio (20/29) Aug 20 2016 This syntax would be very confusing to a non-expert. It is a
- Engine Machine (11/45) Aug 20 2016 Do you not realize that if every human endeavor was to bow down
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the above
way. Essentially an alias is created for us automatically)
Type(T) : Type!nullinherits only if T is not null(or a type that
inherits from itself, which would then be valid).
Type!Dog inherits from Type/Type!null.
Type!T inherits from Type/Type!null as long as T != null.
Members in base(null) are not re-included in derived(e.g., int x;
isn't include in Type!Dog because it's already there from base).
This simple syntactic sugar allows us to create multiple classes
to create simple inheritance hierarchy.
It replaces the current method of having to define a
non-templated class and a templated class.
e.g.,
class Type
{
int x;
}
class Type(T) : Type
{
static if (T is Dog)
int y;
}
vs
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Aug 19 2016
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
It replaces the current method of having to define a
non-templated class and a templated class.
e.g.,
class Type
{
int x;
}
class Type(T) : Type
{
static if (T is Dog)
int y;
}
What are you talking about? This code doesn't compile. Because
you can't define a class and a template with the same name.
Aug 19 2016
Engine Machine <EM EM.com> On Friday, 19 August 2016 at 19:13:10 UTC, Jack Applegame wrote:On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:It doesn't matter. That is just a defect of D/language. If it confuses you, call it Type_Special_X, or, if that confuses you, call it something else. Don't get caught up in the words old padawan.It replaces the current method of having to define a non-templated class and a templated class. e.g., class Type { int x; } class Type(T) : Type { static if (T is Dog) int y; }What are you talking about? This code doesn't compile. Because you can't define a class and a template with the same name.
Aug 19 2016
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the above
way. Essentially an alias is created for us automatically)
Type(T) : Type!nullinherits only if T is not null(or a type
that inherits from itself, which would then be valid).
Type!Dog inherits from Type/Type!null.
Type!T inherits from Type/Type!null as long as T != null.
Members in base(null) are not re-included in derived(e.g., int
x; isn't include in Type!Dog because it's already there from
base).
This simple syntactic sugar allows us to create multiple
classes to create simple inheritance hierarchy.
It replaces the current method of having to define a
non-templated class and a templated class.
e.g.,
class Type
{
int x;
}
class Type(T) : Type
{
static if (T is Dog)
int y;
}
vs
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
1) `null` has a very precise meaning: it is the only valid value
of an unnamed type only known as `typeof(null)`, which implicitly
converts to any class/pointer/dynamic array/associative array
type. Thus this thing should have a different name.
2) What about this case:
```
class Type(T): Type
{
static if (T is Dog)
int y;
else
float z;
}
```
What should be inside the base?
3) I guess that you may find this useful to write functions that
accept any type this way:
```
void myFunction(Type val)
{
// only use fields in common between all Type instantiations
}
```
But you can already do that this way, which is way more flexible:
```
void myFunction(T)(Type!T val)
{
// use fields in common between all instantiation,
// but also fields specific to a certain instantiation,
// using static if
}
```
4) I think that the value of this addition is little wrt. the
amount of work the compiler should do to implement it (which at
first sight would be a lot). But this is of course just my
opinion.
Aug 19 2016
On Friday, 19 August 2016 at 19:19:35 UTC, Lodovico Giaretta wrote:On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:null as many interpretations. It is ok to expand the meaning. It is done all the time. If it confuses you are creates a semantic difficulty, I don't mind what it is called. It could be called Boomfurkasufasdf. In this case, defining it to be null fits in semantically though. If it creates some compiler issue then, again, anything else could be used. I'd prefer Null or NULL or Aleph or something short and meaningless.So we can create types relationships easier: class Type(T) : Type!null { int x; static if (T is Dog) int y; } Type == Type!null (!null implicit, only if defined in the above way. Essentially an alias is created for us automatically) Type(T) : Type!nullinherits only if T is not null(or a type that inherits from itself, which would then be valid). Type!Dog inherits from Type/Type!null. Type!T inherits from Type/Type!null as long as T != null. Members in base(null) are not re-included in derived(e.g., int x; isn't include in Type!Dog because it's already there from base). This simple syntactic sugar allows us to create multiple classes to create simple inheritance hierarchy. It replaces the current method of having to define a non-templated class and a templated class. e.g., class Type { int x; } class Type(T) : Type { static if (T is Dog) int y; } vs class Type(T) : Type!null { int x; static if (T is Dog) int y; }1) `null` has a very precise meaning: it is the only valid value of an unnamed type only known as `typeof(null)`, which implicitly converts to any class/pointer/dynamic array/associative array type. Thus this thing should have a different name.2) What about this case: ``` class Type(T): Type { static if (T is Dog) int y; else float z; } ``` What should be inside the base?z.3) I guess that you may find this useful to write functions that accept any type this way: ``` void myFunction(Type val) { // only use fields in common between all Type instantiations } ``` But you can already do that this way, which is way more flexible: ``` void myFunction(T)(Type!T val) { // use fields in common between all instantiation, // but also fields specific to a certain instantiation, // using static if } ```Well, that is not really what I'm after. I am after simplifying class design.4) I think that the value of this addition is little wrt. the amount of work the compiler should do to implement it (which at first sight would be a lot). But this is of course just my opinion.It is just syntactic sugar and requires no complex compiler modifications. The benefit is reduced visual complexity and that is always a bonus. That is the point we don't write in 0's and 1's... everything else is just syntactic sugar. In this case, it is a very simple rewrite rule. A few lines of code would be all that is required.
Aug 19 2016
On Friday, 19 August 2016 at 21:51:38 UTC, Engine Machine wrote:On Friday, 19 August 2016 at 19:19:35 UTC, Lodovico Giaretta wrote:The problem is that null is a valid value to instantiate an alias template parameter with. So using it to do something completely different may create ambiguity (does that null means "parent template" or is it a valid instantiation? Who knows). But as you said, this is just a matter of finding a name.1) `null` has a very precise meaning: it is the only valid value of an unnamed type only known as `typeof(null)`, which implicitly converts to any class/pointer/dynamic array/associative array type. Thus this thing should have a different name.null as many interpretations. It is ok to expand the meaning. It is done all the time. If it confuses you are creates a semantic difficulty, I don't mind what it is called. It could be called Boomfurkasufasdf. In this case, defining it to be null fits in semantically though. If it creates some compiler issue then, again, anything else could be used. I'd prefer Null or NULL or Aleph or something short and meaningless.This is wrong. If Type has to be the base class of every Type!T, then it cannot contain z, as there is one Type!T (namely Type!Dog) which does not contain z. So in this case the base class Type should be empty. As you see it is not that simple.2) What about this case: ``` class Type(T): Type { static if (T is Dog) int y; else float z; } ``` What should be inside the base?z.I am after simplifying class design.Fair enough. Though I'm not sure this is the right way to go.I'm not an expert, but I think this requires *a lot* of compiler work: it has to analyze every symbol in the class to find out whether it must be part of the "uninstantiated" base or not. And this kind of analysis may not be easy (it may be masked by the use of traits, template mixins, string mixins and so on). Even humans can easily get it wrong (see my previous example). Also, I thought of other problems: - Interaction with non-class templates: how should they behave? Or are we just introducing a special case for class templates? (Special cases are very bad, we should limit them). - Interaction with base classes and interfaces: how is this "uninstantiated base class" inserted into the graph of classes and interfaces? Are interfaces considered implemented by this base class? Is this base class inserted between the templated class and the "original" base class?4) I think that the value of this addition is little wrt. the amount of work the compiler should do to implement it (which at first sight would be a lot). But this is of course just my opinion.It is just syntactic sugar and requires no complex compiler modifications. The benefit is reduced visual complexity and that is always a bonus. That is the point we don't write in 0's and 1's... everything else is just syntactic sugar. In this case, it is a very simple rewrite rule. A few lines of code would be all that is required.
Aug 19 2016
On Friday, 19 August 2016 at 22:20:29 UTC, Lodovico Giaretta wrote:On Friday, 19 August 2016 at 21:51:38 UTC, Engine Machine wrote:Yes, but in this case it is used in a very specific and exact sense, so it is not arbitrarily ambiguous. Again, if it is, then just use some other syntax.On Friday, 19 August 2016 at 19:19:35 UTC, Lodovico Giaretta wrote:The problem is that null is a valid value to instantiate an alias template parameter with. So using it to do something completely different may create ambiguity (does that null means "parent template" or is it a valid instantiation? Who knows). But as you said, this is just a matter of finding a name.1) `null` has a very precise meaning: it is the only valid value of an unnamed type only known as `typeof(null)`, which implicitly converts to any class/pointer/dynamic array/associative array type. Thus this thing should have a different name.null as many interpretations. It is ok to expand the meaning. It is done all the time. If it confuses you are creates a semantic difficulty, I don't mind what it is called. It could be called Boomfurkasufasdf. In this case, defining it to be null fits in semantically though. If it creates some compiler issue then, again, anything else could be used. I'd prefer Null or NULL or Aleph or something short and meaningless.Yeah, T should be empty. This is not a good example though because one wouldn't compose such things like this. It is quite simple when one follows the logical guidelines. The code would "work" but the inheritance hierarchy would not be correct and the compiler would spit out errors, as it should. So, even if I mis-reasoned about it(quickly glanced over it without thinking), it doesn't change anything though. Base would be empty and technically we would have two types of derived types. One of Dog with y in it and everything else with z in it, call it E. Dog and E would just be derived types of Type. It is no different than class Type(T): Type { static if (T is Dog) int y; else static if (T !is Dog) float z; } which is semantically equivalent to class Type(T): Type { static if (T is Dog) int y; else static if (T is E) float z; } Where E is everything that is not a Dog.This is wrong. If Type has to be the base class of every Type!T, then it cannot contain z, as there is one Type!T (namely Type!Dog) which does not contain z. So in this case the base class Type should be empty. As you see it is not that simple.2) What about this case: ``` class Type(T): Type { static if (T is Dog) int y; else float z; } ``` What should be inside the base?z.Yes, it might. But if it is truly just semantic sugar, then it shouldn't pose any problem because it's just a rewrite. Obviously I am not suggesting it just be written up in a New York minute and thrown in the code. It needs to be properly analyzed and such.I'm not an expert, but I think this requires *a lot* of compiler work: it has to analyze every symbol in the class to find out whether it must be part of the "uninstantiated" base or not. And this kind of analysis may not be easy (it may be masked by the use of traits, template mixins, string mixins and so on). Even humans can easily get it wrong (see my previous example).4) I think that the value of this addition is little wrt. the amount of work the compiler should do to implement it (which at first sight would be a lot). But this is of course just my opinion.It is just syntactic sugar and requires no complex compiler modifications. The benefit is reduced visual complexity and that is always a bonus. That is the point we don't write in 0's and 1's... everything else is just syntactic sugar. In this case, it is a very simple rewrite rule. A few lines of code would be all that is required.Also, I thought of other problems: - Interaction with non-class templates: how should they behave? Or are we just introducing a special case for class templates? (Special cases are very bad, we should limit them). - Interaction with base classes and interfaces: how is this "uninstantiated base class" inserted into the graph of classes and interfaces? Are interfaces considered implemented by this base class? Is this base class inserted between the templated class and the "original" base class?I think you are making it too complicated. This is a grammar transformation. If the syntax is grammatically equivalent to something already implementable in the language, then one only has to make sure the new syntactic sugar does not collide with pre-existing semantic evaluations. Basically, if the compiler can always transform it in to valid code and the new syntax doesn't create ambiguous or wrong interpretations, then it is valid. Since I've already said that basically it is a simplification of the type system for classes, and have hinted at the rewrite rules(of course, I didn't specify them with mathematical exactness because there is no point, it isn't my job and I am not qualified in the first place), really only the second issue has to be addressed. But the second issue generally just finding the proper syntax(e.g., use null or not). People that are familiar with D's internals are far better equipped to know these issues than I am. It isn't that it can't be done, it is, "How much do the D maintainers care enough about the problem". It is generally that they don't care too much about it because they themselves don't see it as a problem. Hence, why should I make such efforts to specify things exactly when chances are it won't get implemented in the first place? Generally it's "If it can be done in the library then it should". And since this can be done, more or less, in a library and it is not a significant language enhancement, it won't be implement in D. For example, If I propose the following syntactic sugar: class Alpha^5 { } which expands to class Alpha1 { } class Alpha2 { } class Alpha3 { } class Alpha4 { } class Alpha5 { } then the only question is can the current compiler interpret ^n unambiguously and without undue complexity. If it can, and such a syntactic rewrite is useful, then it should be implemented. It is obvious that the transformation itself does not introduce anything new and hence, in and of itself, does not break anything. In fact, by definition, it can't. If something has well defined mapping rules between the new semantics and the old, then it can't break anything inherently. Only the syntax itself could create problems for the specific implementation(e.g., using null which then creates ambiguity or problems in parsing). But syntax is relatively meaningless. Any syntax will do, I am not too concerned about such trivialities as long as it doesn't increase the language complexity(which is why I suggested such a shorthand in the first place, because it is simpler). My point is, with all this mumbo jumbo, is that we shouldn't "argue" over whether short hand notation is correct or not, if the mapping is pretty clear(should be crystal clear if it is implemented but that's for later). Arguing over how much it adds to the language vs taking away and the proper syntax is what is important. To be precise: If a language L1 and pre-processor P can transform in to a new language L2 = P(L1), and L2 is valid in some respect(such as a properly comparable program) then L1 is valid as an extension of L2. This is function composition and just works thanks to mathematics. The only question, is it worth while to "update"(implement the pre-processor as part of the compiler, say) L2 to become L1, so we don't need a pre-processor. I can't answer this because what is worth while to me is not necessarily worth-while to those that can actually do something about it. If I cared enough, I would fork dmd or implement my own language and compiler... Anyways, all of it is meaningless, not like this has a shot at actually being implemented. Luckily there seems to be a good enough approximate solution that I can sleep at night ;)
Aug 19 2016
On Fri, 19 Aug 2016 23:43:05 +0000, Engine Machine wrote:then the only question is can the current compiler interpret ^n unambiguously and without undue complexity. If it can, and such a syntactic rewrite is useful, then it should be implemented.No. You must weigh the added complexity against the benefits. The less frequently a feature will be used, the more surprise you will inflict on people when they encounter it. The less like other things in the language this new feature is, the more awkward it will be for users. You called your suggestion "syntactic sugar", but if we can call it that, we can say the same of templates. Your implication that it is a simple change is incorrect. Your proposal clashes with existing features. It's even a breaking change. It's implemented easily enough by hand with: class SomeFoo { // common fields and methods, possibly abstract } class Foo(T) : SomeFoo { // everything else } The by-hand implementation is also more obvious. You would have to change the proposed syntax, show that this can't be reasonably done in a library, and show what it gives you that's appreciably better than what's currently there.
Aug 19 2016
On 19.08.2016 20:25, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
alias Seq(T...)=T;
template TypeParent(T...) if(T.length==1){
static if(is(typeof(T[0])==typeof(null))) alias TypeParent = Seq!();
else alias TypeParent = Seq!(Type!null);
}
class Type(T...): TypeParent!T if(T.length==1){
int x;
static if (T is Dog)
int y;
}
Aug 19 2016
On Friday, 19 August 2016 at 21:07:42 UTC, Timon Gehr wrote:On 19.08.2016 20:25, Engine Machine wrote:This is a bit verbose and not quite right (T is Dog should be something like T[0], or whatever). It does essentially work. My only complaint is that it would be nice to be able to export an alias to Type!() = Type; in the namespace of the type being created. Doubt that D can do that!? If it can, then it should be an adequate solution. That is It would be nice to have something like alias Type = Type!(); class Type(T...): TypeParent!T if(T.length==1){ int x; static if (T is Dog) int y; } Again, I don't think D will allow this. alias Seq(T...)=T; template TypeParent(T...) { static if(is(typeof(T[0])==typeof(null))) alias TypeParent = Seq!(); else alias TypeParent = Seq!(Type!null); } class Type(T...) : TypeParent!T { int x; static if(T.length == 1) { static if (T[0] is Dog) int y; } } (note I removed the length checks, so we can create the base type and such) I guess a such a method is nice to create compound types though: Type!(Animal, Dog, Chihuahua) and have a inheritance chain. e.g., class Type(T...) : TypeParent!T { int x; static if(T.length >= 1) { static if (T[0] is "Animal") { int z; static if (T[1] is "Dog") int y; } } } void main() { Type!("Animal", "Dog") t; } I don't know if all this obeys inheritance though but it looks like it should. Thanks!So we can create types relationships easier: class Type(T) : Type!null { int x; static if (T is Dog) int y;alias Seq(T...)=T; template TypeParent(T...) if(T.length==1){ static if(is(typeof(T[0])==typeof(null))) alias TypeParent = Seq!(); else alias TypeParent = Seq!(Type!null); } class Type(T...): TypeParent!T if(T.length==1){ int x; static if (T is Dog) int y; }
Aug 19 2016
On 20.08.2016 00:07, Engine Machine wrote:On Friday, 19 August 2016 at 21:07:42 UTC, Timon Gehr wrote:Apart from the workaround for the ridiculous alias template parameter semantics, I think the length of the code more or less matches the specificity of the requested behaviour. (There should be ways to abstract out most of it, in case you need this really often.)On 19.08.2016 20:25, Engine Machine wrote:This is a bit verboseSo we can create types relationships easier: class Type(T) : Type!null { int x; static if (T is Dog) int y;alias Seq(T...)=T; template TypeParent(T...) if(T.length==1){ static if(is(typeof(T[0])==typeof(null))) alias TypeParent = Seq!(); else alias TypeParent = Seq!(Type!null); } class Type(T...): TypeParent!T if(T.length==1){ int x; static if (T is Dog) int y; }and not quite right (T is Dog should be something like T[0], or whatever). ...('T is Dog' does not work anyway.)It does essentially work. My only complaint is that it would be nice to be able to export an alias to Type!() = Type; in the namespace of the type being created. Doubt that D can do that!? If it can, then it should be an adequate solution. That is It would be nice to have something like alias Type = Type!(); class Type(T...): TypeParent!T if(T.length==1){ int x; static if (T is Dog) int y; }I don't understand how this is related.
Aug 20 2016
On Saturday, 20 August 2016 at 10:04:07 UTC, Timon Gehr wrote:On 20.08.2016 00:07, Engine Machine wrote:Yes, it is not too bad. One doesn't need to T.length part so it is a little shorter. Took me a bit to get used to it.On Friday, 19 August 2016 at 21:07:42 UTC, Timon Gehr wrote:Apart from the workaround for the ridiculous alias template parameter semantics, I think the length of the code more or less matches the specificity of the requested behaviour. (There should be ways to abstract out most of it, in case you need this really often.)On 19.08.2016 20:25, Engine Machine wrote:This is a bit verboseSo we can create types relationships easier: class Type(T) : Type!null { int x; static if (T is Dog) int y;alias Seq(T...)=T; template TypeParent(T...) if(T.length==1){ static if(is(typeof(T[0])==typeof(null))) alias TypeParent = Seq!(); else alias TypeParent = Seq!(Type!null); } class Type(T...): TypeParent!T if(T.length==1){ int x; static if (T is Dog) int y; }Yes, I use strings, but it doesn't really matter, it can be made to work.and not quite right (T is Dog should be something like T[0], or whatever). ...('T is Dog' does not work anyway.)The only difference is the alias Type = Type!(); Again, D can't do this but the point is that it would be nice to have the alias. One can't do everything as a "library" solution. Trying to expand your code results in some odd behavior: public template TypeParent(P) { import std.traits; alias T = TemplateArgsOf!P; alias Seq(T...) = T; static if (T.length == 0 || is(typeof(T[0]) == typeof(null))) { alias TypeParent = Seq!(); } else { alias TypeParent = Seq!(P!(T[0..T.length-1])); } } class Type(T...) : TypeParent!(Type!T) { int x; static if (T.length >= 1 && T[0] is "Animal") { int y; static if (T.length >= 2 && T[1] is "Dog") { int z; static if (T.length >= 3&& T[2] is "Pug") { int s; } } } } void main() { import std.traits; auto a = new Type!("Animal", "Dog", "Pug")(); Type!("Animal", "Dog") b = a; Type!("Animal") c = b; a.s = 1; b.z = 2; c.y = 3; } b and c are of type P!, not Type!It does essentially work. My only complaint is that it would be nice to be able to export an alias to Type!() = Type; in the namespace of the type being created. Doubt that D can do that!? If it can, then it should be an adequate solution. That is It would be nice to have something like alias Type = Type!(); class Type(T...): TypeParent!T if(T.length==1){ int x; static if (T is Dog) int y; }I don't understand how this is related.
Aug 20 2016
On 20.08.2016 21:20, Engine Machine wrote:I see what you are after (but this was not part of the original requirements :) ). I don't think there's a way to make a symbol act as both a type and a template.The only difference is the alias Type = Type!(); Again, D can't do this but the point is that it would be nice to have the alias. One can't do everything as a "library" solution. ...That is It would be nice to have something like alias Type = Type!(); class Type(T...): TypeParent!T if(T.length==1){ int x; static if (T is Dog) int y; }I don't understand how this is related.Trying to expand your code results in some odd behavior: public template TypeParent(P) { import std.traits; alias T = TemplateArgsOf!P; alias Seq(T...) = T; static if (T.length == 0 || is(typeof(T[0]) == typeof(null))) { alias TypeParent = Seq!(); } else { alias TypeParent = Seq!(P!(T[0..T.length-1])); } } class Type(T...) : TypeParent!(Type!T) { int x; static if (T.length >= 1 && T[0] is "Animal") { int y; static if (T.length >= 2 && T[1] is "Dog") { int z; static if (T.length >= 3&& T[2] is "Pug") { int s; } } } } void main() { import std.traits; auto a = new Type!("Animal", "Dog", "Pug")(); Type!("Animal", "Dog") b = a; Type!("Animal") c = b; a.s = 1; b.z = 2; c.y = 3; } b and c are of type P!, not Type!It seems that this is a compiler bug. Is the problem just with getting a string representation of the type?
Aug 20 2016
On Sunday, 21 August 2016 at 00:44:01 UTC, Timon Gehr wrote:On 20.08.2016 21:20, Engine Machine wrote:Well, I see that a template with 0 parameters can act as a "type", if you will. Just like functions void foo(T)(T x) acts like a normal function foo(3) even though it is a templated function. In fact, I see very little difference between a template with 0 parameters and a type. Type!() = Type seems very natural an logical to me as long as Type isn't defined anywhere else... but that is a problem in all cases(e.g., even functions). Maybe there is some good reason though that simplifies the compiler.I see what you are after (but this was not part of the original requirements :) ). I don't think there's a way to make a symbol act as both a type and a template.The only difference is the alias Type = Type!(); Again, D can't do this but the point is that it would be nice to have the alias. One can't do everything as a "library" solution. ...That is It would be nice to have something like alias Type = Type!(); class Type(T...): TypeParent!T if(T.length==1){ int x; static if (T is Dog) int y; }I don't understand how this is related.I think it is just that D isn't "unaliasing" the template parameter, P in this case, to what it aliases... It makes it seem like things are different. Why one would have to keep track of internal template aliases is beyond me. D should rewrite the internal parameters in to meaningful external scope parameters if possible(which should be possible since it must know the input to the template).Trying to expand your code results in some odd behavior: public template TypeParent(P) { import std.traits; alias T = TemplateArgsOf!P; alias Seq(T...) = T; static if (T.length == 0 || is(typeof(T[0]) == typeof(null))) { alias TypeParent = Seq!(); } else { alias TypeParent = Seq!(P!(T[0..T.length-1])); } } class Type(T...) : TypeParent!(Type!T) { int x; static if (T.length >= 1 && T[0] is "Animal") { int y; static if (T.length >= 2 && T[1] is "Dog") { int z; static if (T.length >= 3&& T[2] is "Pug") { int s; } } } } void main() { import std.traits; auto a = new Type!("Animal", "Dog", "Pug")(); Type!("Animal", "Dog") b = a; Type!("Animal") c = b; a.s = 1; b.z = 2; c.y = 3; } b and c are of type P!, not Type!It seems that this is a compiler bug. Is the problem just with getting a string representation of the type?
Aug 21 2016
On Sunday, 21 August 2016 at 21:21:22 UTC, Engine Machine wrote:Well, I see that a template with 0 parameters can act as a "type", if you will. Just like functions void foo(T)(T x) acts like a normal function foo(3) even though it is a templated function. In fact, I see very little difference between a template with 0 parameters and a type. Type!() = TypeI think this is a very bad idea theory-wise, if not in practice as well. A template is a type constructor, not a type. They are two very different things. You can get the size of a type, its members, etc. while you cannot for a template.
Aug 22 2016
On Monday, 22 August 2016 at 15:58:14 UTC, Meta wrote:On Sunday, 21 August 2016 at 21:21:22 UTC, Engine Machine wrote:Yeah, maybe... but I think this is a user issue and not a language issue. The programmer should attempt to know what he is doing. I'd prefer to use an extended ascii syntax so we can have proper categorization of things. e.g., æType - a type ½Template - a template Or whatever. That way it is very easy to know what is what ;) Symbols may vary...Well, I see that a template with 0 parameters can act as a "type", if you will. Just like functions void foo(T)(T x) acts like a normal function foo(3) even though it is a templated function. In fact, I see very little difference between a template with 0 parameters and a type. Type!() = TypeI think this is a very bad idea theory-wise, if not in practice as well. A template is a type constructor, not a type. They are two very different things. You can get the size of a type, its members, etc. while you cannot for a template.
Aug 22 2016
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the above
way. Essentially an alias is created for us automatically)
Type(T) : Type!nullinherits only if T is not null(or a type
that inherits from itself, which would then be valid).
Type!Dog inherits from Type/Type!null.
Type!T inherits from Type/Type!null as long as T != null.
Members in base(null) are not re-included in derived(e.g., int
x; isn't include in Type!Dog because it's already there from
base).
Something like this:
class Type(T: typeof(null)) { //< L1 (specialization)
int x;
}
class Dog {}
class Type(T) : Type!(typeof(null)) { //< L2 (`typeof(null)`)
static if(is(T: Dog)) //< L3 (`is(MyType: IntendedType)` or
`is(MyType == ExactType)`)
int y;
}
What you're looking for is "specialization", on line "L1". Also
some corrections on lines "L2" and "L3"
Aug 19 2016
On Friday, 19 August 2016 at 22:20:09 UTC, Enamex wrote:On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:How is this any different, besides adding meaningless complexity, to inheritence as it already is?[...]Something like this: class Type(T: typeof(null)) { //< L1 (specialization) int x; } class Dog {} class Type(T) : Type!(typeof(null)) { //< L2 (`typeof(null)`) static if(is(T: Dog)) //< L3 (`is(MyType: IntendedType)` or `is(MyType == ExactType)`) int y; } What you're looking for is "specialization", on line "L1". Also some corrections on lines "L2" and "L3"
Aug 19 2016
On Friday, 19 August 2016 at 23:12:39 UTC, Engine Machine wrote:On Friday, 19 August 2016 at 22:20:09 UTC, Enamex wrote:Um, not sure what you mean. This isn't suggesting adding anything; it's already legal/compiles.On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:How is this any different, besides adding meaningless complexity, to inheritence as it already is?[...]Something like this: class Type(T: typeof(null)) { //< L1 (specialization) int x; } class Dog {} class Type(T) : Type!(typeof(null)) { //< L2 (`typeof(null)`) static if(is(T: Dog)) //< L3 (`is(MyType: IntendedType)` or `is(MyType == ExactType)`) int y; } What you're looking for is "specialization", on line "L1". Also some corrections on lines "L2" and "L3"
Aug 19 2016
On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:
So we can create types relationships easier:
class Type(T) : Type!null
{
int x;
static if (T is Dog)
int y;
}
Type == Type!null (!null implicit, only if defined in the above
way. Essentially an alias is created for us automatically)
This syntax would be very confusing to a non-expert. It is a
special case of an existing features (inheritance and templates),
which makes it hard to learn about, as all resources are going to
discuss those other features first, and only the most detailed
readings are going to contain this detail. Moreover, it does not
introduce a keyword or any other name, so it is almost impossible
to Google. Try googling something like "template<class T> class a
class b: public a<b>", and see which result contains "curiously
recurring template pattern". It is hard to find, isn't it?
Moreover, as indicated by another poster, null is already a valid
template parameter, making it even more confusing. Also it is
unclear when the interpretation would be as you propose.
You need to appreciate the difference between write-only code and
code that can be easily read, reviewed and understood.
Dlang has already went too far in inventing pieces of non-obvious
syntax for template features. Lets not make the situation worse.
Distill what you want to do, see what use cases are covered by
other features and libraries, name your thing accordingly and
then propose.
Aug 20 2016
On Saturday, 20 August 2016 at 13:45:59 UTC, poliklosio wrote:On Friday, 19 August 2016 at 18:25:06 UTC, Engine Machine wrote:Do you not realize that if every human endeavor was to bow down to the lowest common denominator there would be no point? If Walter had the notion "I have to make D so the beginner can understand it easily" Then D would be javascript or php? If you want to be an idiot and use an idiot language, then there are many out there. Go program in BASIC. So your arguments appealing to ignorance(not the logical fallacy, of course) is non-sense. Life is complex, stop trying to reduce it to something you already can understand. I think, technically, this is called laziness.So we can create types relationships easier: class Type(T) : Type!null { int x; static if (T is Dog) int y; } Type == Type!null (!null implicit, only if defined in the above way. Essentially an alias is created for us automatically)This syntax would be very confusing to a non-expert. It is a special case of an existing features (inheritance and templates), which makes it hard to learn about, as all resources are going to discuss those other features first, and only the most detailed readings are going to contain this detail. Moreover, it does not introduce a keyword or any other name, so it is almost impossible to Google. Try googling something like "template<class T> class a class b: public a<b>", and see which result contains "curiously recurring template pattern". It is hard to find, isn't it? Moreover, as indicated by another poster, null is already a valid template parameter, making it even more confusing. Also it is unclear when the interpretation would be as you propose. You need to appreciate the difference between write-only code and code that can be easily read, reviewed and understood. Dlang has already went too far in inventing pieces of non-obvious syntax for template features. Lets not make the situation worse. Distill what you want to do, see what use cases are covered by other features and libraries, name your thing accordingly and then propose.
Aug 20 2016