I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you
don't need to explicitly specify the scope of the enum value.
This would reduce redundancy in typing, just like automatic type
inference does.
Examples:
On 29-09-2012 03:55, Tommi wrote:
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you don't
need to explicitly specify the scope of the enum value. This would
reduce redundancy in typing, just like automatic type
On Saturday, 29 September 2012 at 02:01:15 UTC, Alex Rønne
Petersen wrote:
The first issue with this proposal that comes to mind is this:
enum Foo { bar }
void func(Foo f)
{
// ...
}
// ...
Foo bar = Foo.bar;
func(bar); // ?
Maybe it should simply throw a compile error about the ambigui
On 29-09-2012 04:31, Tommi wrote:
On Saturday, 29 September 2012 at 02:01:15 UTC, Alex Rønne Petersen wrote:
The first issue with this proposal that comes to mind is this:
enum Foo { bar }
void func(Foo f)
{
// ...
}
// ...
Foo bar = Foo.bar;
func(bar); // ?
Maybe it should simply thro
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you
don't need to explicitly specify the scope of the enum value.
This would reduce redundancy in typing, just like automatic
type inference does.
Examples:
On Saturday, September 29, 2012 03:55:48 Tommi wrote:
> enum MyFruit { apple, orange, banana }
>
> MyFruit fruit;
>
> switch (fruit)
> {
> case apple: break; // Case expressions know what type to
> case orange: break; // expect based on the switch expression
> case banana: break;
On 9/29/12, David Piepgrass wrote:
> I like the spirit of this feature, but as Alex pointed out,
> ambiguity is possible (which could theoretically cause errors in
> existing code)
It could also cause subtle problems because enum values are implicitly
convertible to the enum's base type. Take thi
On 9/29/12, Jonathan M Davis wrote:
> you could simply use with to solve the problem:
>
> with(MyFruit)
> {
> switch(fruit)
> {
> case apple: break;
> case orange: break;
> case banana: break;
> }
> }
>
It's even simpler:
switch(fruit) with (MyFruit)
{
case
On Saturday, 29 September 2012 at 02:37:40 UTC, Alex Rønne
Petersen wrote:
Regardless of the conditions under which to throw an error, it
would be a breaking change.
I guess that's a bad thing. Hmmm... too bad.
Well... maybe we could make it so that variables of the requested
enum type are
On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
Plus, I don't like the fact that when you see something like
"MyIterator!forward" by itself in code, there is no obvious
clue that forward is an enum value and not a class name or a
variable. So there is a sort of decrease
So, these would be the new rules we'd give to the compiler:
1) See if you can compile the code exactly the way you've been
doing it thus far. If it compiles, great, we're done.
2) Else, if there are undefined identifiers that are passed to
places where named enum variables are expected, try t
On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
Plus, I don't like the fact that when you see something like
"MyIterator!forward" by itself in code, there is no obvious
clue that forward is an enum value and not a class name or a
variable.
I might also add, that once
On 29-09-2012 06:06, Tommi wrote:
So, these would be the new rules we'd give to the compiler:
1) See if you can compile the code exactly the way you've been doing it
thus far. If it compiles, great, we're done.
2) Else, if there are undefined identifiers that are passed to places
where named en
On Saturday, 29 September 2012 at 04:26:01 UTC, Alex Rønne
Petersen wrote:
It's an awful lot of magic (it's not as easy in the
implementation as it sounds like) for questionable gain when we
have the with statement IMO.
"it's not as easy in the implementation as it sounds like"
-
On Saturday, 29 September 2012 at 05:08:12 UTC, Tommi wrote:
then that's completely an unacceptable argument. The question
of how much work it is to implement, has nothing to do with
whether it's a good feature to have or not. And that's what
we're discussing.
Except a theoretical feature doe
2012/9/29 Tommi :
> On Saturday, 29 September 2012 at 04:26:01 UTC, Alex Rønne Petersen wrote:
>>
>>
>> It's an awful lot of magic (it's not as easy in the implementation as it
>> sounds like) for questionable gain when we have the with statement IMO.
>
>
> "it's not as easy in the implementation a
On 29 September 2012 04:12, Andrej Mitrovic wrote:
> On 9/29/12, Jonathan M Davis wrote:
>> you could simply use with to solve the problem:
>>
>> with(MyFruit)
>> {
>> switch(fruit)
>> {
>> case apple: break;
>> case orange: break;
>> case banana: break;
>> }
>
Yeah, to respond to the larger topic, the with statement
is more than enough here. I'm not convinced that complicating
lookup rules further is worth it.
On Saturday, 29 September 2012 at 05:47:59 UTC, Bernard Helyer
wrote:
Except a theoretical feature doesn't exist, so someone has
to write the code. So no, it's not an 'unacceptable
argument'.
I'll explain my way of seeing this in the form we all understand:
code.
bool tryImplement(Feature x
On 29/09/2012 04:11, Andrej Mitrovic wrote:
On 9/29/12, David Piepgrass wrote:
I like the spirit of this feature, but as Alex pointed out,
ambiguity is possible (which could theoretically cause errors in
existing code)
It could also cause subtle problems because enum values are implicitly
con
On Saturday, 29 September 2012 at 07:04:19 UTC, kenji hara wrote:
After a while, you may add a global variable in module scope.
enum E { foo ,bar }
int foo = 10;
void test(E e) {}
void main() {
test(foo); // foo is defined, and look up module scope foo.
// Then, now the code is
But, if we were allowed to make a breaking change, then this is
how I think it should work:
// in a module scope...
enum E { foo, bar };
-
// These cause a compile error "foo is ambiguous":
1) E foo = E.bar;
2) E foo = E.foo;
3) enum
On 9/29/12 2:44 PM, Tommi wrote:
But, if we were allowed to make a breaking change
I stopped reading here :o).
Andrei
Scratch my previous post. It had a weird rule where the types of
identifiers had a say in whether or not there's ambiguity in the
name lookup. That's just silly. It should always be an ambiguity
error if the names are identical.
This new rule is easier to conceptualize too. Basically you just
Although it's not very obvious what is a "hot-spot" and what is
not.
enum Char { a, b, c, d }
Char a = c; // OK: 'c' is in a "hot-spot"
Char b = c + 1; // ERROR: 'c' is undefined, because it's not in
// a "hot-spot" and therefore Char enumerations
// aren't visi
On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you
don't need to explicitly specify the scope of the enum value.
This would reduce redun
On Saturday, 29 September 2012 at 23:49:47 UTC, Tommi wrote:
It is quite a mess. I think I'm ready to admit that this is not
a feature we'd like to have in this language (probably not in
any language for that matter).
Using "with" should do the trick just fine for the few situations
where the
Le 29/09/2012 14:04, Bernard Helyer a écrit :
Yeah, to respond to the larger topic, the with statement
is more than enough here. I'm not convinced that complicating
lookup rules further is worth it.
Well, they are not complicated, they are mostly undefined.
28 matches
Mail list logo
