www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The Sweet With

reply Tomasz Sowi&#324;ski <tomeksowi wp.pl> writes:
Ideas for features based on the with.

The with can make calling functions with enum arguments sexier. So instead of:
auto d = dirEntries(".", SpanMode.breadth);

you could say:
auto d = dirEntries(".", breadth);

by declaring the function as:
dirEntries(string path, with SpanMode mode);    // "with" does the trick

At first glance, such feature seems lesser. But I noticed that for fear of
redundancy programmers resort to cluttering the global scope with constants, or
even worse - using bool to offer only two options. So when the API needs an
equivalent of GUI's dropdown list, the with encourages the right way - enums.


The with can also tidy up numerous imports:

import extremely.long.package.name.module1;
import extremely.long.package.name.module2;
import extremely.long.package.name.module3;
import renamed = extremely.long.package.name.module4;
import extremely.long.package.name.module5 : selective;
...

could be compressed to:

import with (extremely.long.package.name)
{
    module1;
    module2;
    module3;
    renamed = module4;
    module5 : selective;
    ...
}

or even:

import with (extremely.long.package.name)
    module1, module2, module3, renamed = module4, module5 : selective, ... ;


What do you say?

Tomek
Mar 03 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:


 Ideas for features based on the with.
 
 The with can make calling functions with enum arguments sexier. So instead of:
 auto d = dirEntries(".", SpanMode.breadth);
 
 you could say:
 auto d = dirEntries(".", breadth);
 
 by declaring the function as:
 dirEntries(string path, with SpanMode mode);    // "with" does the trick


It looks nice, but has a subtle and disastrous problem. In D, arguments 
are fully resolved *before* overloading is done. If some of the 
overloads have with declarations, then there's a nightmarish problem of 
trying to mix overloading and argument resolution together.
Mar 03 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Mar 3, 2009 at 1:50 PM, Walter Bright
<newshound1 digitalmars.com> wrote:



 Ideas for features based on the with.

 The with can make calling functions with enum arguments sexier. So inste=




ad

 of:
 auto d =3D dirEntries(".", SpanMode.breadth);

 you could say:
 auto d =3D dirEntries(".", breadth);

 by declaring the function as:
 dirEntries(string path, with SpanMode mode); =A0 =A0// "with" does the t=




rick

 It looks nice, but has a subtle and disastrous problem. In D, arguments a=


re

 fully resolved *before* overloading is done. If some of the overloads hav=


e

 with declarations, then there's a nightmarish problem of trying to mix
 overloading and argument resolution together.


What about the feature you mentioned at the D con, about being able to
use enums without the enum name?  Or will/would that only be for
things where it's really obvious, like switch statements?
Mar 03 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
 "Jarrett Billingsley" <jarrett.billingsley gmail.com> wrote in message 
 news:mailman.901.1236111433.22690.digitalmars-d puremagic.com...
 On Tue, Mar 3, 2009 at 1:50 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:



 Ideas for features based on the with.

 The with can make calling functions with enum arguments sexier. So 
 instead
 of:
 auto d = dirEntries(".", SpanMode.breadth);

 you could say:
 auto d = dirEntries(".", breadth);

 by declaring the function as:
 dirEntries(string path, with SpanMode mode); // "with" does the trick


 It looks nice, but has a subtle and disastrous problem. In D, arguments 
 are
 fully resolved *before* overloading is done. If some of the overloads 
 have
 with declarations, then there's a nightmarish problem of trying to mix
 overloading and argument resolution together.


 What about the feature you mentioned at the D con, about being able to
 use enums without the enum name?  Or will/would that only be for
 things where it's really obvious, like switch statements?


Unless that was only for things like switch statements, I would hate that. 
I've used enums in languages that worked that way, and I found it to be such 
a problematic namespace-clutterer that in those languages I always hack up 
my enum definitions like this:

enum Color
{
    Color_Red,
    Color_Blue,
    Color_Orange,
    // etc...
}

Which is a style that I've always considered an ugly and kludgey, but 
unfortunately necessary, substitute for manditory enum names.
Mar 03 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Mar 3, 2009 at 3:32 PM, Nick Sabalausky <a a.a> wrote:

 "Jarrett Billingsley" <jarrett.billingsley gmail.com> wrote in message
 news:mailman.901.1236111433.22690.digitalmars-d puremagic.com...
 On Tue, Mar 3, 2009 at 1:50 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:



 Ideas for features based on the with.

 The with can make calling functions with enum arguments sexier. So
 instead
 of:
 auto d =3D dirEntries(".", SpanMode.breadth);

 you could say:
 auto d =3D dirEntries(".", breadth);

 by declaring the function as:
 dirEntries(string path, with SpanMode mode); // "with" does the trick


 It looks nice, but has a subtle and disastrous problem. In D, argument=






s

 are
 fully resolved *before* overloading is done. If some of the overloads
 have
 with declarations, then there's a nightmarish problem of trying to mix
 overloading and argument resolution together.


 What about the feature you mentioned at the D con, about being able to
 use enums without the enum name? =A0Or will/would that only be for
 things where it's really obvious, like switch statements?


 Unless that was only for things like switch statements, I would hate that=


.

 I've used enums in languages that worked that way, and I found it to be s=


uch

 a problematic namespace-clutterer that in those languages I always hack u=


p

 my enum definitions like this:

 enum Color
 {
 =A0 =A0Color_Red,
 =A0 =A0Color_Blue,
 =A0 =A0Color_Orange,
 =A0 =A0// etc...
 }

 Which is a style that I've always considered an ugly and kludgey, but
 unfortunately necessary, substitute for manditory enum names.


Oh, the way he described it in the slides was different.  As in,
normally you would use Color.Red, but inside a switch:

switch(widgetColor)
{
    case Red: // this is *completely* unambiguous
}

And such.  Red is not a global; it's rather that name lookup is
changed for some constructs.
Mar 03 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 What about the feature you mentioned at the D con, about being able to
 use enums without the enum name?  Or will/would that only be for
 things where it's really obvious, like switch statements?


As I recall, only some of that would work because of this problem.
Mar 03 2009
prev sibling next sibling parent reply Tomasz Sowi&#324;ski <tomeksowi wp.pl> writes:
Walter Bright Wrote:


 It looks nice, but has a subtle and disastrous problem. In D, arguments 
 are fully resolved *before* overloading is done. If some of the 
 overloads have with declarations, then there's a nightmarish problem of 
 trying to mix overloading and argument resolution together.


Not sure if I understand right. Can you write up a simple example of the
nightmare?

Tomek
Mar 05 2009
parent Sergey Gromov <snake.scaly gmail.com> writes:



 Walter Bright Wrote:
 

 It looks nice, but has a subtle and disastrous problem. In D, arguments 
 are fully resolved *before* overloading is done. If some of the 
 overloads have with declarations, then there's a nightmarish problem of 
 trying to mix overloading and argument resolution together.


 
 Not sure if I understand right. Can you write up a simple example of the
nightmare?
 
 Tomek


I think Walter means that types of argument expressions are determined
first, and only then a set of compatible overloads is composed.  Say you
have

enum Foo { one, two }
int one;

void bar(int x);  // (1)
void bar(with Foo x);  // (2)

bar(one);

Currently, D will determine that expression 'one' is of type int, then
search for bar(int) or compatible, and will find (1).  With your
proposal, you must first find all 'bar's, determine that *some* of them
have 'with' arguments, and now what?  Infer type for the first argument
differently for (1) and (2), so that for (1) it's int, and for (2) it's
Foo?  Or add the Foo to the scope, so that the first argument is of type
Foo even for (1)?  I can't see a good solution.
Mar 05 2009
prev sibling parent reply Tomasz Sowi&#324;ski <tomeksowi wp.pl> writes:
Sergey Gromov Wrote:



 

 Walter Bright Wrote:
 

 It looks nice, but has a subtle and disastrous problem. In D, arguments 
 are fully resolved *before* overloading is done. If some of the 
 overloads have with declarations, then there's a nightmarish problem of 
 trying to mix overloading and argument resolution together.


 
 Not sure if I understand right. Can you write up a simple example of the
nightmare?
 
 Tomek


 
 I think Walter means that types of argument expressions are determined
 first, and only then a set of compatible overloads is composed.  Say you
 have
 
 enum Foo { one, two }
 int one;
 
 void bar(int x);  // (1)
 void bar(with Foo x);  // (2)
 
 bar(one);
 
 Currently, D will determine that expression 'one' is of type int, then
 search for bar(int) or compatible, and will find (1).  With your
 proposal, you must first find all 'bar's, determine that *some* of them
 have 'with' arguments, and now what?  Infer type for the first argument
 differently for (1) and (2), so that for (1) it's int, and for (2) it's
 Foo?  Or add the Foo to the scope, so that the first argument is of type
 Foo even for (1)?  I can't see a good solution.


A blunt one would be screaming out an error whenever the compiler has trouble
choosing an overload. Would it be too hard to live with?
Mar 10 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Sorry about the name...



 A blunt one would be screaming out an error whenever the compiler has trouble
choosing an overload. Would it be too hard to live with?


For programmers? It would be ugly.

For the compiler? It would be ugly, and result in a lot of 
special-casing, I feel. With current with statements, you start a new 
scope and add a bunch of symbols to it. Using this proposed with 
statement syntax, you don't create a new scope, so you have to add a 
step or three to resolving symbols.

Also, you'd have to find all possible overloads of a function and do 
some semantic analysis on them before you could resolve the arguments. 
Overload resolution becomes a lot more difficult.

And what does the programmer gain? Very little. People seldom use enums, 
I think.
Mar 10 2009
parent "Nick Sabalausky" <a a.a> writes:
"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:gp6p96$2dp9$1 digitalmars.com...

 Sorry about the name...



 A blunt one would be screaming out an error whenever the compiler has 
 trouble choosing an overload. Would it be too hard to live with?


 For programmers? It would be ugly.

 For the compiler? It would be ugly, and result in a lot of special-casing, 
 I feel. With current with statements, you start a new scope and add a 
 bunch of symbols to it. Using this proposed with statement syntax, you 
 don't create a new scope, so you have to add a step or three to resolving 
 symbols.

 Also, you'd have to find all possible overloads of a function and do some 
 semantic analysis on them before you could resolve the arguments. Overload 
 resolution becomes a lot more difficult.

 And what does the programmer gain? Very little. People seldom use enums, I 
 think.


I use enums all the time. But I don't mind prepending "MyEnumType." to enum 
literals. It would be nice to have a shortcut in clear-cut cases, but if it 
meant a bunch of special casing and such, I can certainly live without it.
Mar 10 2009