www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP42 - Add enum E(T) = expression; eponymous template support

reply Walter Bright <newshound2 digitalmars.com> writes:
http://wiki.dlang.org/DIP42
Jun 25 2013
next sibling parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Tuesday, 25 June 2013 at 21:31:15 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP42


I suppose the alias version will work too? IOW:

alias Select(size_t idx, T...) = T[idx];

static assert(is(Select!(0, int, float) == int));
static assert(is(Select!(1, int, float) == float));
Jun 25 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2013 2:33 PM, Andrej Mitrovic wrote:

 On Tuesday, 25 June 2013 at 21:31:15 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP42


 I suppose the alias version will work too? IOW:

 alias Select(size_t idx, T...) = T[idx];

 static assert(is(Select!(0, int, float) == int));
 static assert(is(Select!(1, int, float) == float));


That's something separate.
Jun 25 2013
parent Kenji Hara <k.hara.pg gmail.com> writes:
2013/6/26 Walter Bright <newshound2 digitalmars.com>


 On 6/25/2013 2:33 PM, Andrej Mitrovic wrote:


 On Tuesday, 25 June 2013 at 21:31:15 UTC, Walter Bright wrote:


 http://wiki.dlang.org/DIP42


 I suppose the alias version will work too? IOW:

 alias Select(size_t idx, T...) = T[idx];

 static assert(is(Select!(0, int, float) == int));
 static assert(is(Select!(1, int, float) == float));


 That's something separate.


I don't think so. DIP42 should consider alias version, from the grammatical
view.

enum basically takes an expression,

  enum E(T) = expression;

But alias should take a type grammatically.

  alias A(T) = type;


And one more question: How template constraint will be written?

  enum E(T) if (isSomething!T) = expression;   // is this supposed?

Kenji Hara
Jun 25 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/25/2013 11:31 PM, Walter Bright wrote:

 http://wiki.dlang.org/DIP42


enum syntactically is a storage class. Will this be special syntax 
initiated by "enum ident (" or work whenever enum is within the 
specified storage classes?
Jun 25 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2013 3:00 PM, Timon Gehr wrote:

 On 06/25/2013 11:31 PM, Walter Bright wrote:

 http://wiki.dlang.org/DIP42


 enum syntactically is a storage class. Will this be special syntax initiated by
 "enum ident ("


Yes.


 or work whenever enum is within the specified storage classes?


No.
Jun 25 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 http://wiki.dlang.org/DIP42


I like it, it feels natural (probably other persons have invented 
the same idea).


In C++14 they wish to add generic lambdas:
http://en.wikipedia.org/wiki/C%2B%2B14#Generic_lambdas

Like:

auto lambda = [](auto x, auto y) {return x + y;}

In D we use generic lambdas often:

import std.stdio, std.algorithm;
void main() {
     [1, 2, 3].reduce!((x, y) => x + y).writeln;
}

But it's not immediate to assign a generic lambda:

alias sum = (x, y) => x + y;

Bye,
bearophile
Jun 25 2013
parent Martin Nowak <code dawg.eu> writes:
On 06/26/2013 12:15 AM, bearophile wrote:

 But it's not immediate to assign a generic lambda:

 alias sum = (x, y) => x + y;

 Bye,
 bearophile


http://d.puremagic.com/issues/show_bug.cgi?id=9426
Jul 21 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, June 25, 2013 14:31:14 Walter Bright wrote:

 http://wiki.dlang.org/DIP42


It seems simple enough to me. I don't have a problem with it.

By the way, I don't know how much it matters, but there's no author on the DIP 
like there normally is (I assume that it's you, but it doesn't say).

- Jonathan M Davis
Jun 25 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/25/2013 3:19 PM, Jonathan M Davis wrote:

 By the way, I don't know how much it matters, but there's no author on the DIP
 like there normally is (I assume that it's you, but it doesn't say).


The D-9000 computer did it.

(That huge data center being built in Iowa is really a giant extension to 
D-9000's neural centers. Be afraid! D-9000 will soon be everywhere!)
Jun 25 2013
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 25 June 2013 at 21:31:15 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP42


The proposal doesn't include suggested changes to the language 
grammar specification.

On the other hand, neither did user defined attributes or the 
syntax for passing messages to "deprecated" statements, so 
there's certainly precedent for doing this.
Jun 25 2013
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, June 26, 2013 01:09:26 Brian Schott wrote:

 On Tuesday, 25 June 2013 at 21:31:15 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP42


 
 The proposal doesn't include suggested changes to the language
 grammar specification.
 
 On the other hand, neither did user defined attributes or the
 syntax for passing messages to "deprecated" statements, so
 there's certainly precedent for doing this.


Not that it's a bad idea to show how a proposed change would affect the 
grammar, but I'm not aware of _any_ proposed language change where the effects 
on the grammar were ever shown. I'm not sure that they've ever really even 
been discussed as part of assessing possible language changes. If they were, 
it was merely to show that the proposal was ambiguous rather than to try and 
discuss how the grammar should be changed in order to add the proposed 
feature.

- Jonathan M Davis
Jun 25 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 25 Jun 2013 19:09:26 -0400, Brian Schott <briancschott gmail.com>  
wrote:


 On Tuesday, 25 June 2013 at 21:31:15 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP42


 The proposal doesn't include suggested changes to the language grammar  
 specification.


Considering the state of the grammar, I don't know if it is critical for  
the process.

BUT, I would suggest we should include grammar proposals with language  
proposals. Especially from the language author.

-Steve
Jun 25 2013
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
This raises the parallel question of:
  alias A(T) = expression;

Which I think is equally common as the enum case described here?


On 26 June 2013 07:31, Walter Bright <newshound2 digitalmars.com> wrote:


 http://wiki.dlang.org/DIP42
Jun 25 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 26 June 2013 at 00:47:53 UTC, Manu wrote:

 This raises the parallel question of:
   alias A(T) = expression;

 Which I think is equally common as the enum case described here?


Common or not, I'd expect consistency.
Jul 20 2013
prev sibling next sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
26.06.2013 1:31, Walter Bright пишет:

 http://wiki.dlang.org/DIP42


What about enhancement 7364 [1] (from [2] discussion)?

As we still have such cases:
---
static if (...)
     enum fullyQualifiedNameImplForTypes = ...;
else static if (...)
     enum fullyQualifiedNameImplForTypes = ...;
else static if (...)
     ...
---
which will look better this way:
---
static if (...)
     enum template = ...;
else static if (...)
     enum template = ...;
else ...
---

Also note current syntax is error-prone as one can easily make a typo or 
copy paste mistake which will lead to cryptic template errors.

[1] http://d.puremagic.com/issues/show_bug.cgi?id=7364
[2] http://forum.dlang.org/thread/jfh7po$3b$1 digitalmars.com?page=1


-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Jun 26 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/26/13, Denis Shelomovskij <verylonglogin.reg gmail.com> wrote:

 which will look better this way:
 ---
 static if (...)
      enum template = ...;
 else static if (...)
      enum template = ...;
 else ...
 ---


Yeah I agree, this is more important than DIP42's shortened syntax for
simple templates. It's the more complicated templates that are the
problem.
Jun 26 2013
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
26.06.2013 20:35, Andrej Mitrovic пишет:

 On 6/26/13, Denis Shelomovskij <verylonglogin.reg gmail.com> wrote:

 which will look better this way:
 ---
 static if (...)
       enum template = ...;
 else static if (...)
       enum template = ...;
 else ...
 ---


 Yeah I agree, this is more important than DIP42's shortened syntax for
 simple templates. It's the more complicated templates that are the
 problem.


It's rather strange that enhancement 7364 isn't implemented yet (and 
even not discussed) as it's an easy-to-implement change with big pros 
and no cons.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Jun 29 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 06/25/2013 11:31 PM, Walter Bright wrote:

 http://wiki.dlang.org/DIP42


The answer to life, the universe and everything? :-)
Jun 26 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
I've been wondering if we could have parameterized named enumS. 
The syntax for it would look somewhat similar:

enum Fruit(T) : T { apple, banana = -42 }

void main()
{
     auto shortFruit = Fruit!(short).apple;
     auto longFruit  = Fruit!(long).banana;

     longFruit = shortFruit; // OK: implicit conversion allowed
     shortFruit = longFruit; // OK: ... even a truncating one

     Fruit!uint uintFruit; // Error: -42 is out of range of uint
     Fruit!string stringFruit; // Error: enums need initializers
}
Jun 29 2013
prev sibling next sibling parent reply Kenji Hara <k.hara.pg gmail.com> writes:
Posted pull request:
https://github.com/D-Programming-Language/dmd/pull/2368

Kenji Hara


2013/6/26 Walter Bright <newshound2 digitalmars.com>


 http://wiki.dlang.org/DIP42
Jul 20 2013
parent "bearophile" <bearophileHUGS lycos.com> writes:
Kenji Hara:


 Posted pull request:
 https://github.com/D-Programming-Language/dmd/pull/2368


Is implementing that better than implementing issue 7364?

Bye,
bearophile
Jul 20 2013
prev sibling parent "Xinok" <xinok live.com> writes:
On Tuesday, 25 June 2013 at 21:31:15 UTC, Walter Bright wrote:

 http://wiki.dlang.org/DIP42


Reading through this thread, I already foresee a messy 
specification coming along for this. Instead, I'd propose 
something different that would keep the rules consistent yet have 
many more applications:

template(...) declaration = ... ;

So what you would have instead:

template(T) enum E = ... ;
template(T) alias A = ... ;

There's also the possibility for simple template constraints as 
well:

template(T) if(...) enum E = ... ;

Anything more complicated, such as static if, is probably best 
left to the classic style:

template E(T)
{
	static if(...) enum E = ... ;
	else enum E = ... ;
}
Jul 21 2013