www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "with" should be deprecated with extreme prejudice

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I think "with" is a very dangerous feature due to the way it hides 
symbols. It essentially makes the feeblest attempt at modular reasoning 
utterly impossible:

int x, y;
with (whatever)
{
     y += x;
     ++x;
}

What can be said about such code? Nothing. If whatever has or will ever 
have fields x or y or both, the names will bind to them; otherwise, 
they'll bind to the locals. Non-local code dependency at its finest.

Maintenance of any type that is being used with "with" becomes a very 
dangerous proposition because it can silently change meaning of code.

I therefore submit that "with" is an extremely dangerous feature and 
should be removed from the language. What say you?


Andrei
May 17 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular reasoning
 utterly impossible:
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
 What can be said about such code? Nothing. If whatever has or will ever
 have fields x or y or both, the names will bind to them; otherwise,
 they'll bind to the locals. Non-local code dependency at its finest.
 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
 I therefore submit that "with" is an extremely dangerous feature and
 should be removed from the language. What say you?
 Andrei


Absolutely not.  It's far too useful as syntactic sugar when working heavily
with
plain old data structs, and saves a lot of tedious repetition of the struct
instance name.  There are lots of similar bonehead things one could do.  For
one,
think of the opposite:  accidentally declaring a local variable in a member
function that hides the struct- or class-level variable.  I see your point, but
I
simply think the benefits drastically outweigh the downsides.  You can pry
with()
out of my cold, dead hands.
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article

 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular reasoning
 utterly impossible:
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
 What can be said about such code? Nothing. If whatever has or will ever
 have fields x or y or both, the names will bind to them; otherwise,
 they'll bind to the locals. Non-local code dependency at its finest.
 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.
 I therefore submit that "with" is an extremely dangerous feature and
 should be removed from the language. What say you?
 Andrei


 
 Absolutely not.  It's far too useful as syntactic sugar when working heavily
with
 plain old data structs, and saves a lot of tedious repetition of the struct
 instance name.


Make it a member function! If you don't have access to the struct, use 
"s." as the prefix! I can't believe that's stopping you from getting 
work done!


 There are lots of similar bonehead things one could do.  For one,
 think of the opposite:  accidentally declaring a local variable in a member
 function that hides the struct- or class-level variable.  I see your point,
but I
 simply think the benefits drastically outweigh the downsides.  You can pry
with()
 out of my cold, dead hands.


That there are other bad things in D doesn't make "with" any more virtuous!

I think you don't entirely get my point. The "with" statement is almost 
a textbook example of bad language design, creating a mess of 
long-distance dependencies. It is terrible. I can't believe it snuck 
under our nose for so long. It's a radioactive-leaking sarcophagus that 
must be buried.


Andrei
May 17 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Andrei,


 dsimcha wrote:
 

 Absolutely not.  It's far too useful as syntactic sugar when working
 heavily with plain old data structs, and saves a lot of tedious
 repetition of the struct instance name.
 


 Make it a member function! If you don't have access to the struct, use
 "s." as the prefix! I can't believe that's stopping you from getting
 work done!
 


I don't follow.
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:

 Hello Andrei,
 

 dsimcha wrote:


 Absolutely not.  It's far too useful as syntactic sugar when working
 heavily with plain old data structs, and saves a lot of tedious
 repetition of the struct instance name.


 Make it a member function! If you don't have access to the struct, use
 "s." as the prefix! I can't believe that's stopping you from getting
 work done!


 
 I don't follow.
 
 


"s." is hardly any typing.

Andrei
May 17 2009
parent reply BCS <none anon.com> writes:
Hello Andrei,


 BCS wrote:
 

 Hello Andrei,
 

 dsimcha wrote:
 

 Absolutely not.  It's far too useful as syntactic sugar when
 working heavily with plain old data structs, and saves a lot of
 tedious repetition of the struct instance name.
 


 Make it a member function! If you don't have access to the struct,
 use "s." as the prefix! I can't believe that's stopping you from
 getting work done!
 


 I don't follow.
 


 "s." is hardly any typing.


wrong bit, I should have cut more:


 Make it a member function!


?
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:

 Hello Andrei,
 

 BCS wrote:


 Hello Andrei,


 dsimcha wrote:


 Absolutely not.  It's far too useful as syntactic sugar when
 working heavily with plain old data structs, and saves a lot of
 tedious repetition of the struct instance name.


 Make it a member function! If you don't have access to the struct,
 use "s." as the prefix! I can't believe that's stopping you from
 getting work done!


 I don't follow.


 "s." is hardly any typing.


 
 wrong bit, I should have cut more:
 

 Make it a member function!


 
 ?


In a member function there's no need to prefix each member.

Andrei
May 17 2009
next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:

 In a member function there's no need to prefix each member.


There isn't, but there should be.  IMO.
'with' should be banned.
Implicit access to members of 'this' should also be banned.  I always
use explicit 'this->' in C++ and explicit 'this.' in D.  It makes the
code much easier to read.


-- 
Rainer Deyke - rainerd eldwood.com
May 17 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:

 Andrei Alexandrescu wrote:

 In a member function there's no need to prefix each member.


 
 There isn't, but there should be.  IMO.
 'with' should be banned.
 Implicit access to members of 'this' should also be banned.  I always
 use explicit 'this->' in C++ and explicit 'this.' in D.  It makes the
 code much easier to read.


You see, this is an interesting point. Not using "this." may lead to 
local bugs. The masking effected by "with" may lead to nonlocal bugs. 
The difference in risk is enormous.


Andrei
May 17 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Rainer Deyke" <rainerd eldwood.com> wrote in message 
news:guqno8$2fci$1 digitalmars.com...

 Andrei Alexandrescu wrote:

 In a member function there's no need to prefix each member.


 There isn't, but there should be.  IMO.
 'with' should be banned.
 Implicit access to members of 'this' should also be banned.  I always
 use explicit 'this->' in C++ and explicit 'this.' in D.  It makes the
 code much easier to read.


This is what I love about Ruby's member access. It's just like you suggest, 
but with " " prepended instead of "this." which IMO is much too clunky to 
require for something as common as accessing a member of the current 
instance. But other than that little quibble I love the idea.
May 17 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei, I agree that "with" is dangerous when it shadows outer names (Python
designers have not added a "with" because of this).

------------------

Rainer Deyke:


 Implicit access to members of 'this' should also be banned.  I always
 use explicit 'this->' in C++ and explicit 'this.' in D.  It makes the
 code much easier to read.


I too usually add "this." in my D code to increase readability. But it's quite
long (as "self." in Python), so the solution used by Ruby may be better:  
before instance attributes (Ruby also uses    before class attributes, that are
absent in D. D has static variables that are something different and more
primitive).

-------------------

Derek Parnell:


 int x, y;
 with (p as "somevery.long.struct.or.class[17].name") {
       y += p.x;
       ++p.x;
 }


I also use alias to create a shorter name, so it may be used an extension of
the alias syntax (to allow to use {} to define where such alias exists. Also
notice the "as" keyword, used in renamed imports too):

int x, y;
alias somevery.long.struct.or.class[17].name as s {
      y += p.x;
      ++p.x;
}

Bye,
bearophile
May 18 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


They did, but with different semantics =)
It's used for RAII (I guess you already know that, but maybe other people
don't).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20090518141908.GB9277 burns.springfield.home...

 bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


 They did, but with different semantics =)
 It's used for RAII (I guess you already know that, but maybe other people
 don't).
May 18 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Nick Sabalausky, el 18 de mayo a las 15:23 me escribiste:

 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...

 bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


 They did, but with different semantics =)
 It's used for RAII (I guess you already know that, but maybe other people
 don't).


 





In Python, with calls a special method at the begining and some other
special method at the end of the block:

with lock:
	do_something()

is like:

lock.__enter__()
try:
	do_something
finally:
	lock.__exit__()

Or something like that. I think you can use a special method to be called
if an exception was raised (similar to scope(exit|failure|success)).

You can also do something like:

with file("some file") as f:
	x = f.read()

to define an alias to a "temporary" object, so you can work with it.
f.__enter__() does nothing and f.__exit__() closes the file.

This is what I remember, for a full, authoritative, description:
http://www.python.org/doc/2.5/whatsnew/pep-343.html

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 18 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:




http://effbot.org/pyref/context-managers.htm
http://www.python.org/dev/peps/pep-0343/

Bye,
bearophile
May 18 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...

 bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


 They did, but with different semantics =)
 It's used for RAII (I guess you already know that, but maybe other people
 don't).


 



What a God awful feature. Honestly, "what were they sinking about?" 


Andrei
May 18 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:

 Nick Sabalausky wrote:

 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...

 bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


 They did, but with different semantics =)
 It's used for RAII (I guess you already know that, but maybe other 
 people
 don't).





 
 What a God awful feature. Honestly, "what were they sinking about?" 

 
 Andrei


http://msdn.microsoft.com/en-us/library/aa664736.aspx
May 18 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:

 Andrei Alexandrescu wrote:

 Nick Sabalausky wrote:

 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...

 bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


 They did, but with different semantics =)
 It's used for RAII (I guess you already know that, but maybe other 
 people
 don't).





 What a God awful feature. Honestly, "what were they sinking about?" 


 Andrei


 
 http://msdn.microsoft.com/en-us/library/aa664736.aspx


I meant: "explain what were they sinking about when they designed this 
awful feature", not "explain this awful feature in detail". I know the 
feature, and that doesn't help its case.

Andrei
May 18 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 18 May 2009 16:14:29 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 Nick Sabalausky wrote:

 "Leandro Lucarella" <llucax gmail.com> wrote in message  
 news:20090518141908.GB9277 burns.springfield.home...

 bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


 They did, but with different semantics =)
 It's used for RAII (I guess you already know that, but maybe other  
 people
 don't).





 What a God awful feature. Honestly, "what were they sinking about?"  



Had to look it up, never used it.

Not sure it's that terrible, it looks to be the equivalent in D of:

{
   scope C = new C();
   ...
}

I suppose it's good in cases where you want to have somewhat manual memory  
management.  Does seem poorly named though.

-Steve
May 18 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Steven Schveighoffer wrote:

 On Mon, 18 May 2009 16:14:29 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Nick Sabalausky wrote:

 "Leandro Lucarella" <llucax gmail.com> wrote in message 
 news:20090518141908.GB9277 burns.springfield.home...

 bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


 They did, but with different semantics =)
 It's used for RAII (I guess you already know that, but maybe other 
 people
 don't).





 What a God awful feature. Honestly, "what were they sinking about?" 



 
 Had to look it up, never used it.
 
 Not sure it's that terrible, it looks to be the equivalent in D of:
 
 {
   scope C = new C();
   ...
 }
 
 I suppose it's good in cases where you want to have somewhat manual 
 memory management.  Does seem poorly named though.


Or transactions, or locking, or similar things.

One of the interesting uses of it that I've seen is in Rhino Mocks:
using (Mocks.Ordered())
{
	everything in this block records expected calls where the order matters
}
but over here, order doesn't matter.
May 18 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 1:14 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:

 "Leandro Lucarella" <llucax gmail.com> wrote in message
 news:20090518141908.GB9277 burns.springfield.home...

 bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


 They did, but with different semantics =)
 It's used for RAII (I guess you already know that, but maybe other people
 don't).





 What a God awful feature. Honestly, "what were they sinking about?" People



Looks like

using(Foo x = new Foo()) {
     // do stuff
}

It's basically equiv of

{
    auto x = new Foo();
    scope(exit) foo.Dispose;
    // do stuff
}

So it saves a little typing but is capable of less.  scope(exit) is way cooler.

"with".  http://effbot.org/zone/python-with-statement.htm

--bb
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, May 18, 2009 at 1:14 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Nick Sabalausky wrote:

 "Leandro Lucarella" <llucax gmail.com> wrote in message
 news:20090518141908.GB9277 burns.springfield.home...

 bearophile, el 18 de mayo a las 04:33 me escribiste:

 Andrei, I agree that "with" is dangerous when it shadows outer names
 (Python designers have not added a "with" because of this).


 They did, but with different semantics =)
 It's used for RAII (I guess you already know that, but maybe other people
 don't).





 What a God awful feature. Honestly, "what were they sinking about?" People



 
 Looks like
 
 using(Foo x = new Foo()) {
      // do stuff
 }
 
 It's basically equiv of
 
 {
     auto x = new Foo();
     scope(exit) foo.Dispose;
     // do stuff
 }
 
 So it saves a little typing but is capable of less.  scope(exit) is way cooler.

 "with".  http://effbot.org/zone/python-with-statement.htm


That's not an "equiv of". It's "completely missing the point of". Each 
"using" costs one new scope and one level of indentation which makes it 

the class when try/catch/finally showed with extensive examples just how 
expensive extra indentation is.

Andrei
May 18 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 1:36 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 That's not an "equiv of". It's "completely missing the point of". Each
 "using" costs one new scope and one level of indentation which makes it

 class when try/catch/finally showed with extensive examples just how
 expensive extra indentation is.


Oh.  Is that the only thing that bothers you about it?
That doesn't bother me much since it's basically for things you only
want to hold on to for a short span.  You should either do your
business in a few lines of code and get out of there, or if you can't
then make it a function.   Anyway, if the indentation bugs you, you
can always set emacs up not to indent on "using" blocks.

--bb
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, May 18, 2009 at 1:36 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 That's not an "equiv of". It's "completely missing the point of". Each
 "using" costs one new scope and one level of indentation which makes it

 class when try/catch/finally showed with extensive examples just how
 expensive extra indentation is.


 
 Oh.  Is that the only thing that bothers you about it?
 That doesn't bother me much since it's basically for things you only
 want to hold on to for a short span.  You should either do your
 business in a few lines of code and get out of there, or if you can't
 then make it a function.   Anyway, if the indentation bugs you, you
 can always set emacs up not to indent on "using" blocks.


It's huge! In TDPL, as soon as I show the expansion of two scope(exit)
statements, code became unreadable. No wonder today's software has so
crappy error handling and state leaks: languages seem to make it as hard
as possible to write correct transactional code.

Andrei
May 18 2009
next sibling parent Christopher Wright <dhasenan gmail.com> writes:
Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 1:36 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 That's not an "equiv of". It's "completely missing the point of". Each
 "using" costs one new scope and one level of indentation which makes it

 the
 class when try/catch/finally showed with extensive examples just how
 expensive extra indentation is.


 Oh.  Is that the only thing that bothers you about it?
 That doesn't bother me much since it's basically for things you only
 want to hold on to for a short span.  You should either do your
 business in a few lines of code and get out of there, or if you can't
 then make it a function.   Anyway, if the indentation bugs you, you
 can always set emacs up not to indent on "using" blocks.


 
 It's huge! In TDPL, as soon as I show the expansion of two scope(exit)
 statements, code became unreadable. No wonder today's software has so
 crappy error handling and state leaks: languages seem to make it as hard
 as possible to write correct transactional code.
 
 Andrei



IDisposable. This means the code that actually executes is highly 
non-local, and requires a fair bit of boilerplate. That makes 'using' 
even less maintainable. (This is also my complaint about using RAII for 
scope guards in C++.)
May 18 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 2:56 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 1:36 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 That's not an "equiv of". It's "completely missing the point of". Each
 "using" costs one new scope and one level of indentation which makes it







he

 class when try/catch/finally showed with extensive examples just how
 expensive extra indentation is.


 Oh. =A0Is that the only thing that bothers you about it?
 That doesn't bother me much since it's basically for things you only
 want to hold on to for a short span. =A0You should either do your
 business in a few lines of code and get out of there, or if you can't
 then make it a function. =A0 Anyway, if the indentation bugs you, you
 can always set emacs up not to indent on "using" blocks.


 It's huge! In TDPL, as soon as I show the expansion of two scope(exit)
 statements, code became unreadable. No wonder today's software has so
 crappy error handling and state leaks: languages seem to make it as hard
 as possible to write correct transactional code.


I agree that scope(exit) is a more general solution that allows for
more interesting tricks.
I think I'm only disagreeing with you on the magnitude of the lameness.


You can always create a new scope if you want one, but you can't
remove a scope if it is defined to be a part of the construct.  So to
me it seems clear that not building the scope into the construct is
the way to go.   This is also a strike against D's current with(),
which also forces a new scope whether you want it or not.

---
In related news, scope(exit) is not without it's own issues.  Mainly,
this doesn't seem nice to me:

void foo() {
   auto x =3D new Thing;
   scope(exit) x.doADance();
   // bunch of code
   x =3D otherThing;
   // more code
}

This will happily doADance on otherThing instead of the original x

re-assignment, but I have not investigated this.  Anyone know?

--bb
May 18 2009
prev sibling parent reply Joel Lucsy <jjlucsy gmail.com> writes:
Andrei Alexandrescu wrote:

 <SeeWebsiteForEmail erdani.org> wrote:
 using(Foo x = new Foo()) {
      // do stuff
 }

 It's basically equiv of

 {
     auto x = new Foo();
     scope(exit) foo.Dispose;
     // do stuff
 }


 That's not an "equiv of". It's "completely missing the point of". Each 
 "using" costs one new scope and one level of indentation which makes it 

 the class when try/catch/finally showed with extensive examples just how 
 expensive extra indentation is.


You can mitigate this somewhat by realizing that multiple usings can be 
wrapped into only one indentation level. Like:

using (Bar bar = new Bar())
using (Foo foo = new Foo())
using (Jim jim = new Jim())
{
     //do something
}

-- 
Joel Lucsy
"The dinosaurs became extinct because they didn't have a space program." 
-- Larry Niven
May 19 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Joel Lucsy wrote:

 Andrei Alexandrescu wrote:

 <SeeWebsiteForEmail erdani.org> wrote:
 using(Foo x = new Foo()) {
      // do stuff
 }

 It's basically equiv of

 {
     auto x = new Foo();
     scope(exit) foo.Dispose;
     // do stuff
 }


 That's not an "equiv of". It's "completely missing the point of". Each 
 "using" costs one new scope and one level of indentation which makes 

 missed the class when try/catch/finally showed with extensive examples 
 just how expensive extra indentation is.


 
 You can mitigate this somewhat by realizing that multiple usings can be 
 wrapped into only one indentation level. Like:
 
 using (Bar bar = new Bar())
 using (Foo foo = new Foo())
 using (Jim jim = new Jim())
 {
     //do something
 }
 


Thanks, that's a good point.

(It's a limited option, though. My code uses scope() statements to do 
things transactionally (e.g. search Phobos for scope) and the pattern 
sometimes is to do some work, plant a scope(), then do some work, plan 
another, etc. This would be difficult with using().)

Andrei
May 19 2009
prev sibling parent reply BCS <none anon.com> writes:
Hello Andrei,


 BCS wrote:
 

 Hello Andrei,
 

 BCS wrote:
 

 Hello Andrei,
 

 dsimcha wrote:
 

 Absolutely not.  It's far too useful as syntactic sugar when
 working heavily with plain old data structs, and saves a lot of
 tedious repetition of the struct instance name.
 


 Make it a member function! If you don't have access to the struct,
 use "s." as the prefix! I can't believe that's stopping you from
 getting work done!
 


 I don't follow.
 


 "s." is hardly any typing.
 


 wrong bit, I should have cut more:
 

 Make it a member function!
 


 ?
 


 In a member function there's no need to prefix each member.
 
 Andrei
 



how does that heplp you when you either don't have access to the type or 
don't want to add the code using the type to it


module somelib;

struct S
{
    int x, y, z;
}


module someapp;
import somelib;

void fn(char[] str, S s)
{
    with(s)
    {
         sscanf(str.ptr, "<%i, %i, %i>", &x, &z, &y); // I'm not adding this 
to S
    }
}
May 17 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff5f598cba54ecba238c8 news.digitalmars.com...

 void fn(char[] str, S s)
 {
    with(s)
    {
         sscanf(str.ptr, "<%i, %i, %i>", &x, &z, &y); // I'm not adding 
 this to S
    }
 }


You don't really see that as an improvement over this do you?:

void fn(char[] str, S s)
{
    sscanf(str.ptr, "<%i, %i, %i>", &s.x, &s.z, &s.y);
}

If anything, the "with" version looks worse to me, and those three "s." are 
trivial.
May 17 2009
parent BCS <none anon.com> writes:
Hello Nick,


 "BCS" <none anon.com> wrote in message
 news:a6268ff5f598cba54ecba238c8 news.digitalmars.com...
 

 void fn(char[] str, S s)
 {
 with(s)
 {
 sscanf(str.ptr, "<%i, %i, %i>", &x, &z, &y); // I'm not adding
 this to S
 }
 }


 You don't really see that as an improvement over this do you?:
 
 void fn(char[] str, S s)
 {
 sscanf(str.ptr, "<%i, %i, %i>", &s.x, &s.z, &s.y);
 }
 If anything, the "with" version looks worse to me, and those three
 "s." are trivial.
 


I do like it over the full form:

void someFn()
{
  static void fn(char[] str, S s)
  {
     sscanf(str.ptr, "<%i, %i, %i>", &s.x, &s.z, &s.y);
  }
  fn(str);
}
May 17 2009
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Andrei Alexandrescu wrote:


 It is terrible. I can't believe it snuck under our nose for so long.


I wrote about that more than four years ago:
http://www.digitalmars.com/d/archives/digitalmars/D/15653.html

-manfred
May 18 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Manfred Nowak wrote:

 Andrei Alexandrescu wrote:
 

 It is terrible. I can't believe it snuck under our nose for so long.


 
 I wrote about that more than four years ago:
 http://www.digitalmars.com/d/archives/digitalmars/D/15653.html


Very well put. I'm very sorry that costly mistake wasn't fixed at that time.

Andrei
May 18 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
 
 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.
 
 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.
 
 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?
 
 
 Andrei


How about we keep in D's tradition and outlaw shadowing instead? I use "with"
rarely, but appreciate it when I do.
May 17 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 Andrei Alexandrescu Wrote:
 

 I think "with" is a very dangerous feature due to the way it hides
  symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y; with (whatever) { y += x; ++x; }
 
 What can be said about such code? Nothing. If whatever has or will
 ever have fields x or y or both, the names will bind to them;
 otherwise, they'll bind to the locals. Non-local code dependency at
 its finest.
 
 Maintenance of any type that is being used with "with" becomes a
 very dangerous proposition because it can silently change meaning
 of code.
 
 I therefore submit that "with" is an extremely dangerous feature
 and should be removed from the language. What say you?
 
 
 Andrei


 
 How about we keep in D's tradition and outlaw shadowing instead? I
 use "with" rarely, but appreciate it when I do.


That's a good alternative. At least if someone introduces a field name 
in the struct and that clashes with something you see, you'll have an error.

Andrei
May 17 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jason House wrote:

 Andrei Alexandrescu Wrote:
 

 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:

 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }

 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.

 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.

 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?


 Andrei


 
 How about we keep in D's tradition and outlaw shadowing instead? I use "with"
rarely, but appreciate it when I do.


This. Just issue an error/warning if something in the with shadows 
something outside. That way, if the struct/class/template/whatever 
changes, affected code will be notified.
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:

 Jason House wrote:

 Andrei Alexandrescu Wrote:


 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular 
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }

 What can be said about such code? Nothing. If whatever has or will 
 ever have fields x or y or both, the names will bind to them; 
 otherwise, they'll bind to the locals. Non-local code dependency at 
 its finest.

 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.

 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?


 Andrei


 How about we keep in D's tradition and outlaw shadowing instead? I use 
 "with" rarely, but appreciate it when I do.


 
 This. Just issue an error/warning if something in the with shadows 
 something outside. That way, if the struct/class/template/whatever 
 changes, affected code will be notified.


No warning, error!

This is a great idea Jason.

Andrei
May 17 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Andrei,


 Robert Fraser wrote:
 

 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.
 


 No warning, error!


warning if it exist, error if used?
May 17 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:

 Hello Andrei,
 

 Robert Fraser wrote:


 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.


 No warning, error!


 
 warning if it exist, error if used?


I go with Walter's stance: either compiles or not. Warnings suck.

Andrei
May 17 2009
parent reply BCS <none anon.com> writes:
Hello Andrei,


 BCS wrote:
 

 Hello Andrei,
 

 Robert Fraser wrote:
 

 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.
 


 No warning, error!
 


 warning if it exist, error if used?
 


 I go with Walter's stance: either compiles or not. Warnings suck.
 
 Andrei
 


warningd are optional and off by default.
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:

 Hello Andrei,
 

 BCS wrote:


 Hello Andrei,


 Robert Fraser wrote:


 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.


 No warning, error!


 warning if it exist, error if used?


 I go with Walter's stance: either compiles or not. Warnings suck.

 Andrei


 
 warningd are optional and off by default.


And that doesn't help either!

Andrei
May 17 2009
parent reply Don <nospam nospam.com> writes:
Andrei Alexandrescu wrote:

 BCS wrote:

 Hello Andrei,


 BCS wrote:


 Hello Andrei,


 Robert Fraser wrote:


 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.


 No warning, error!


 warning if it exist, error if used?


 I go with Walter's stance: either compiles or not. Warnings suck.

 Andrei


 warningd are optional and off by default.


 
 And that doesn't help either!
 
 Andrei


If warnings exist, libraries must not do anything that creates a 
warning. They are NOT optional. Warnings suck.
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:gur1ec$18a$1 digitalmars.com...

 If warnings exist, libraries must not do anything that creates a warning. 
 They are NOT optional.


That's only true if a compiler (such as DMD) is only capable of treating 
warnings as errors.
May 18 2009
parent reply Don <nospam nospam.com> writes:
Nick Sabalausky wrote:

 "Don" <nospam nospam.com> wrote in message 
 news:gur1ec$18a$1 digitalmars.com...

 If warnings exist, libraries must not do anything that creates a warning. 
 They are NOT optional.


 
 That's only true if a compiler (such as DMD) is only capable of treating 
 warnings as errors.


No. Users complain if library code generates warnings. Because a user 
cannot make their code warning-free if the libraries they use are 
generating warnings.
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Don" <nospam nospam.com> wrote in message 
news:gurkuo$17nv$1 digitalmars.com...

 Nick Sabalausky wrote:

 "Don" <nospam nospam.com> wrote in message 
 news:gur1ec$18a$1 digitalmars.com...

 If warnings exist, libraries must not do anything that creates a 
 warning. They are NOT optional.


 That's only true if a compiler (such as DMD) is only capable of treating 
 warnings as errors.


 No. Users complain if library code generates warnings. Because a user 
 cannot make their code warning-free if the libraries they use are 
 generating warnings.


They can if they use a prebuilt version of the library, a lib/a/dll.
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:guscm2$2jff$1 digitalmars.com...

 "Don" <nospam nospam.com> wrote in message 
 news:gurkuo$17nv$1 digitalmars.com...

 Nick Sabalausky wrote:

 "Don" <nospam nospam.com> wrote in message 
 news:gur1ec$18a$1 digitalmars.com...

 If warnings exist, libraries must not do anything that creates a 
 warning. They are NOT optional.


 That's only true if a compiler (such as DMD) is only capable of treating 
 warnings as errors.


 No. Users complain if library code generates warnings. Because a user 
 cannot make their code warning-free if the libraries they use are 
 generating warnings.


 They can if they use a prebuilt version of the library, a lib/a/dll.


Warnings are optional built-in lint tools (kinda like how we already have a 
built-in doc tool, built-in code generation tool (ie, mixins), built-in 
profiling/code-coverage, etc). And it's pretty difficult to claim that lint 
tools are bad. So deciding that (optional) warnings are bad just because 
some people might get warnings from a non-pre-compiled lib and then bitch 
about it is a rather large case of "throwing away the baby with the 
bathwater".

And even aside from pre-compiled lib's (which admittedly probably wouldn't 
work for template-using libs, although I consider that more a problem with 
the existing obj/lib formats than anything else), there are still other 
solutions that don't "throw away the baby with the bathwater". Like maybe a 
switch that only enables warnings for anything in the same package as 
"main". Or "-warn=this.package.only", or "-nowarn=tango", etc.

And before anyone notices that I've filed a bug report in tango for a 
warning despite my "complaining about warnings in libs is silly" stance, 
I'll point out that I've filed bug reports for warnings in libs *only* 
because DMD refuses to allow warnings to actually be treated as warnings (or 

current versions of DMD, fixing warnings are manditory for libs. But that's 
only because DMD's current handling of "warnings" is one hell of a bizarre 
anomoly (ie, In DMD, "warnings" are really "optional errors" at this point, 
*not* true warnings. And yes, *that* kind of so-called "warning" *is* a bad 
thing).
May 18 2009
parent Don <nospam nospam.com> writes:
Nick Sabalausky wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:guscm2$2jff$1 digitalmars.com...

 "Don" <nospam nospam.com> wrote in message 
 news:gurkuo$17nv$1 digitalmars.com...

 Nick Sabalausky wrote:

 "Don" <nospam nospam.com> wrote in message 
 news:gur1ec$18a$1 digitalmars.com...

 If warnings exist, libraries must not do anything that creates a 
 warning. They are NOT optional.


 That's only true if a compiler (such as DMD) is only capable of treating 
 warnings as errors.


 No. Users complain if library code generates warnings. Because a user 
 cannot make their code warning-free if the libraries they use are 
 generating warnings.


 They can if they use a prebuilt version of the library, a lib/a/dll.


 
 Warnings are optional built-in lint tools (kinda like how we already have a 
 built-in doc tool, built-in code generation tool (ie, mixins), built-in 
 profiling/code-coverage, etc). And it's pretty difficult to claim that lint 
 tools are bad.


If they are standardised, they _are_ bad, because they become mandatory 
for libraries. If they're not standardised, no problem, it's just a 
third-party tool which you particular users find helpful in eliminating 
bugs; and demanding that a library support your third-party tool is 
unreasonable.

Warnings can be categorised based on "probability that they indicate a 
bug", with a range from:
(1) it almost always indicates a bug --> in this case, it should be an 
error.
(2) it hardly ever indicates a bug --> in this case, it's useless at 
best, but in practice it's harmful.

If there's anything in between, it indicates a weakness in that part of 
the language design.
DMD's warnings are now extremely close to (1), I hope they can become 
errors soon. (Eg, leaving off a return statement in a function which 
doesn't contain asm statements is almost guaranteed to be a bug).
May 20 2009
prev sibling parent Spacen Jasset <spacenjasset yahoo.co.uk> writes:
BCS wrote:

 Hello Andrei,
 

 Robert Fraser wrote:


 This. Just issue an error/warning if something in the with shadows
 something outside. That way, if the struct/class/template/whatever
 changes, affected code will be notified.


 No warning, error!


 
 warning if it exist, error if used?
 
 


It probably should be an error. Then though, you have the unfortunate 
thing whereby adding something to say struct X will shadow and generate 
a compile error, which you can only fix by:

a) Not using with
b) rename identifier in your sturct
c) rename local variable


I seem to remember some language (I think it's VB) supporting with that 
required a "." prefix in front of with enclosures. Like so:

auto a = 0;
with (foo)
{
	a = 0;
	.a = 1;
}


This is a bit dangerous too though, in terms of typos.
May 18 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 17 May 2009 20:56:14 -0500, Andrei Alexandrescu wrote:


 Andrei Alexandrescu Wrote:


 I think "with" is a very dangerous feature due to the way it hides 
 symbols.








 

 Jason House wrote:
 This. Just issue an error/warning if something in the with shadows 
 something outside. That way, if the struct/class/template/whatever 
 changes, affected code will be notified.




 
On Sun, 17 May 2009 20:56:14 -0500, Andrei Alexandrescu wrote:

 No warning, error!
 
 This is a great idea Jason.


Wow, that's they way I thought it already worked. I never use 'with'
because of the reasons that Andrei has already cited, but if it doesn't
trip such syntax-mines already then I'm even more glad that I haven't used
it.

So yes Jason, that idea has my support too ... though I still can't see me
using the construct anytime soon.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 17 2009
prev sibling next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
     y += x;
     ++x;
 }
 
 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.
 
 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.
 
 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?


Non-touch typers will riot.
May 17 2009
next sibling parent BCS <none anon.com> writes:
Hello Georg,


 Non-touch typers will riot.
 


Not a good reason as nobody cares about us (first person, plural, non inclusive 
of the second person (why can't English have a better set of pronouns?)).
May 17 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:guqdmn$1tks$2 digitalmars.com...

 Andrei Alexandrescu wrote:

 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?


 Non-touch typers will riot.


I'm not a touch-typer, but I've never seen much of a point to "with". If I 
have to access a bunch of members of "foo.member.x.bar[17].fizzle", I'll 
just do "auto fizz = foo.member.x.bar[17].fizzle;" and use that, or put it 
into a function that takes a "typeof(fizze)", or do something else along 
those lines. I've yet to come across a case where something like that isn't 
perfectly sufficient.
May 17 2009
parent reply BCS <none anon.com> writes:
Hello Nick,


 "Georg Wrede" <georg.wrede iki.fi> wrote in message
 news:guqdmn$1tks$2 digitalmars.com...
 

 Andrei Alexandrescu wrote:
 

 I therefore submit that "with" is an extremely dangerous feature and
 should be removed from the language. What say you?
 


 Non-touch typers will riot.
 


 I'm not a touch-typer, but I've never seen much of a point to "with".
 If I have to access a bunch of members of
 "foo.member.x.bar[17].fizzle", I'll just do 
 "auto fizz = foo.member.x.bar[17].fizzle;" and use that, or put it into


that dosn't work if it's by value and is used as an Lvalue.


 a function that takes a "typeof(fizze)", or do something else along


like this? that looks... odd.

void outer()
{
     void inner(ref T t)
     {
          t.somthing;
          ...
     }
     inner(foo.member.x.bar[17].fizzle);
}


 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.
May 17 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff5f5d8cba54f824da454 news.digitalmars.com...

 Hello Nick,


 I'm not a touch-typer, but I've never seen much of a point to "with".
 If I have to access a bunch of members of
 "foo.member.x.bar[17].fizzle", I'll just do "auto fizz = 
 foo.member.x.bar[17].fizzle;" and use that, or put it into


 that dosn't work if it's by value and is used as an Lvalue.


 a function that takes a "typeof(fizze)", or do something else along


 like this? that looks... odd.

 void outer()
 {
     void inner(ref T t)
     {
          t.somthing;
          ...
     }
     inner(foo.member.x.bar[17].fizzle);
 }


 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.




Like I said, "or something along those lines". It all depends on the 
specific code. I just haven't ever had any specific case where I felt like I 
needed "with".
May 17 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky wrote:

 "BCS" <none anon.com> wrote in message 
 news:a6268ff5f5d8cba54f824da454 news.digitalmars.com...

 Hello Nick,


 I'm not a touch-typer, but I've never seen much of a point to "with".
 If I have to access a bunch of members of
 "foo.member.x.bar[17].fizzle", I'll just do "auto fizz = 
 foo.member.x.bar[17].fizzle;" and use that, or put it into


 that dosn't work if it's by value and is used as an Lvalue.


 a function that takes a "typeof(fizze)", or do something else along


 like this? that looks... odd.

 void outer()
 {
     void inner(ref T t)
     {
          t.somthing;
          ...
     }
     inner(foo.member.x.bar[17].fizzle);
 }


 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.




 
 Like I said, "or something along those lines". It all depends on the 
 specific code. I just haven't ever had any specific case where I felt like I 
 needed "with".


I mainly use it for initialization of things:

static S opCall(_x, _y)
{
	S s;
	with(s)
	{
		x = _x;
		y = _y;
		happiness = null;
	}
	return s;
}
May 17 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:guqpkf$2h49$2 digitalmars.com...

 I mainly use it for initialization of things:

 static S opCall(_x, _y)
 {
 S s;
 with(s)
 {
 x = _x;
 y = _y;
 happiness = null;
 }
 return s;
 }


For things like that I have a series of util mixins, for example:

class Foo
{
    int x;
    int y;
    char[] name;
    this(int x, int y, char[] name)
    {
        mixin(initMember!(x, y, name));
    }
}

And even if I didn't, I've never considered the repeated "this." or "s.", 
etc, to be non-trivial enough to really be worth an extra language 
construct - and I'm normally a complete DRY-maniac.
May 17 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sun, May 17, 2009 at 9:53 PM, Robert Fraser
<fraserofthenight gmail.com> wrote:

 Nick Sabalausky wrote:

 "BCS" <none anon.com> wrote in message
 news:a6268ff5f5d8cba54f824da454 news.digitalmars.com...

 Hello Nick,


 I'm not a touch-typer, but I've never seen much of a point to "with".
 If I have to access a bunch of members of
 "foo.member.x.bar[17].fizzle", I'll just do "auto fizz =3D
 foo.member.x.bar[17].fizzle;" and use that, or put it into


 that dosn't work if it's by value and is used as an Lvalue.


 a function that takes a "typeof(fizze)", or do something else along


 like this? that looks... odd.

 void outer()
 {
 =A0 =A0void inner(ref T t)
 =A0 =A0{
 =A0 =A0 =A0 =A0 t.somthing;
 =A0 =A0 =A0 =A0 ...
 =A0 =A0}
 =A0 =A0inner(foo.member.x.bar[17].fizzle);
 }


 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.




 Like I said, "or something along those lines". It all depends on the
 specific code. I just haven't ever had any specific case where I felt li=




ke I

 needed "with".


 I mainly use it for initialization of things:

 static S opCall(_x, _y)
 {
 =A0 =A0 =A0 =A0S s;
 =A0 =A0 =A0 =A0with(s)
 =A0 =A0 =A0 =A0{
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0x =3D _x;
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0y =3D _y;
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0happiness =3D null;
 =A0 =A0 =A0 =A0}
 =A0 =A0 =A0 =A0return s;
 }


I find this to be the most convenient way to transform C++
constructors into struct static opCalls, so I've used it a lot in code
I translated from C++.

But the need there should be eliminated by giving structs real
constructors instead of this static opCall kludge (I thought D2 had
this already, actually...)

One place 'with' is kinda cute is for configuring new objects in a
fire & forget manner:

    with (new WindowWidget) {
              parent =3D mainWin;
              width =3D 100;
              height =3D 100;
    }

That gives you something that works almost like named arguments.

---
On a related note I do think some mechanism similar to C++'s "using"
would be good to have that would let you bring particular namespaces
into the direct lookup scope.  However the same caveats apply --  it
should never be possible to silently change the meaning of code that
has "using foo.bar" by adding or removing something from module
foo.bar.

I think someone proposed allowing aliasing of dot like "alias foo.bar
." to achieve that -- kind of like alias this for structs.

Anyway, I think if you're going to allow co-mingling of module scopes
with top-level imports, then it should also be possible to limit the
mingling to just inner scopes.

--bb
May 18 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser wrote:

 Nick Sabalausky wrote:

 "BCS" <none anon.com> wrote in message 
 news:a6268ff5f5d8cba54f824da454 news.digitalmars.com...

 Hello Nick,


 I'm not a touch-typer, but I've never seen much of a point to "with".
 If I have to access a bunch of members of
 "foo.member.x.bar[17].fizzle", I'll just do "auto fizz = 
 foo.member.x.bar[17].fizzle;" and use that, or put it into


 that dosn't work if it's by value and is used as an Lvalue.


 a function that takes a "typeof(fizze)", or do something else along


 like this? that looks... odd.

 void outer()
 {
     void inner(ref T t)
     {
          t.somthing;
          ...
     }
     inner(foo.member.x.bar[17].fizzle);
 }


 those lines. I've yet to come across a case where something like
 that isn't perfectly sufficient.




 Like I said, "or something along those lines". It all depends on the 
 specific code. I just haven't ever had any specific case where I felt 
 like I needed "with".


 
 I mainly use it for initialization of things:
 
 static S opCall(_x, _y)
 {
     S s;
     with(s)
     {
         x = _x;
         y = _y;
         happiness = null;
     }
     return s;
 }




new S {
   x = _x,
   y = _y,
};

And I think that could replace "with" with no problem, because most of 
the time (or all of the time) you use it when initializing an object.
May 18 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Ary Borenszweig:



 
 new S {
    x = _x,
    y = _y,
 };


Better to add named arguments to methods/functions and templates, it's a more
general solution.

Bye,
bearophile
May 18 2009
prev sibling next sibling parent reply Lester L. Martin II <lestermartin92 gmail.com> writes:
Andrei Alexandrescu Wrote:


 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }
 
 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.
 
 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.
 
 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?
 
 
 Andrei


I agree with dsimcha.

When you do this, do you consider how much code written in D actually uses
this. I find it very, very useful. It's deprecation and further removal would
take a huge hit on my code. What I would propose instead is that you can't
modify variables outside of the scope, but only those that reside in the type
whatever. In this case, you can't possibly change the variables outside of the
with(whatever) scope, but you can modify anything that is in the type whatever,
because this is how I believe it is mainly used. Deprecation of this feature
should never happen. I doubt I and dsimcha will be the only unhappy coders.

Lester L. Martin II
May 17 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lester L. Martin II wrote:

 Andrei Alexandrescu Wrote:
 

 I think "with" is a very dangerous feature due to the way it hides
  symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y; with (whatever) { y += x; ++x; }
 
 What can be said about such code? Nothing. If whatever has or will
 ever have fields x or y or both, the names will bind to them;
 otherwise, they'll bind to the locals. Non-local code dependency at
 its finest.
 
 Maintenance of any type that is being used with "with" becomes a
 very dangerous proposition because it can silently change meaning
 of code.
 
 I therefore submit that "with" is an extremely dangerous feature
 and should be removed from the language. What say you?
 
 
 Andrei


 
 I agree with dsimcha.
 
 When you do this, do you consider how much code written in D actually
 uses this.


That code is a bomb waiting to explode.


 I find it very, very useful.


I believe you don't understand its extreme dangers.


 It's deprecation and further
 removal would take a huge hit on my code.


I understand.


 What I would propose
 instead is that you can't modify variables outside of the scope, but
 only those that reside in the type whatever. In this case, you can't
 possibly change the variables outside of the with(whatever) scope,
 but you can modify anything that is in the type whatever, because
 this is how I believe it is mainly used. Deprecation of this feature
 should never happen. I doubt I and dsimcha will be the only unhappy
 coders.


I think that restriction would be too harsh, as it would make with 
essentially an isolated bubble. Would you be ok with Jason's suggestion 
that shadowing will be flagged? Consider:

struct Widget
{
    //int wyda;
}

void main()
{
     int wyda;
     Widget w;
     with (w)
     {
         wyda = 4;
     }
}

Would you agree to issue a compile-time error upon uncommenting the 
member of Widget.


Andrei
May 17 2009
parent Lester L. Martin II <lestermartin92 gmail.com> writes:
Andrei Alexandrescu Wrote:


 Lester L. Martin II wrote:

 Andrei Alexandrescu Wrote:
 

 I think "with" is a very dangerous feature due to the way it hides
  symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y; with (whatever) { y += x; ++x; }
 
 What can be said about such code? Nothing. If whatever has or will
 ever have fields x or y or both, the names will bind to them;
 otherwise, they'll bind to the locals. Non-local code dependency at
 its finest.
 
 Maintenance of any type that is being used with "with" becomes a
 very dangerous proposition because it can silently change meaning
 of code.
 
 I therefore submit that "with" is an extremely dangerous feature
 and should be removed from the language. What say you?
 
 
 Andrei


 
 I agree with dsimcha.
 
 When you do this, do you consider how much code written in D actually
 uses this.


 
 That code is a bomb waiting to explode.
 

 I find it very, very useful.


 
 I believe you don't understand its extreme dangers.
 

 It's deprecation and further
 removal would take a huge hit on my code.


 
 I understand.
 

 What I would propose
 instead is that you can't modify variables outside of the scope, but
 only those that reside in the type whatever. In this case, you can't
 possibly change the variables outside of the with(whatever) scope,
 but you can modify anything that is in the type whatever, because
 this is how I believe it is mainly used. Deprecation of this feature
 should never happen. I doubt I and dsimcha will be the only unhappy
 coders.


 
 I think that restriction would be too harsh, as it would make with 
 essentially an isolated bubble. Would you be ok with Jason's suggestion 
 that shadowing will be flagged? Consider:
 
 struct Widget
 {
     //int wyda;
 }
 
 void main()
 {
      int wyda;
      Widget w;
      with (w)
      {
          wyda = 4;
      }
 }
 
 Would you agree to issue a compile-time error upon uncommenting the 
 member of Widget.
 
 
 Andrei


I understand that my suggestion makes with a bubble, but I always use and have
always considered its use to mainly be for accessing the members of a variable
and being able to act upon (set) them. That's why I believe that my idea was
good. The shadowing idea will be fine. If I'm right, you can easily just escape
the scope by placing the with statement in a new function if worst comes to
worst and names match in almost every scope. Or it could automagically be made
a member function.
May 17 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello Andrei,


 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.


I'd be willing to go the half way solution of making accessing a shadowing 
symbol an error, resulting in (loudly) not being able to access either.
May 17 2009
parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
BCS wrote:


 Hello Andrei,
 

 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:
 
 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.


 
 I'd be willing to go the half way solution of making accessing a shadowing
 symbol an error, resulting in (loudly) not being able to access either.


I think this solution is a good idea but that removing or restricting
anything more regarding with is a bad idea as others have pointed out.

I'm using with quit a lot and it was one of thous things that attracted me
to D (I get the feeling that D has a quite pragmatic way of looking at
language features, if it's usefull lets have it unless it's harmfull to
other parts of D, sort of.).

On a similar note, Andrei, what is this spree of removing features? Ok some
are obviously bad, imaginary types for example, but why remove other stuff
such as commplex and with?
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Johan Granberg wrote:

 BCS wrote:
 

 Hello Andrei,


 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.


 I'd be willing to go the half way solution of making accessing a shadowing
 symbol an error, resulting in (loudly) not being able to access either.


 
 I think this solution is a good idea but that removing or restricting
 anything more regarding with is a bad idea as others have pointed out.
 
 I'm using with quit a lot and it was one of thous things that attracted me
 to D (I get the feeling that D has a quite pragmatic way of looking at
 language features, if it's usefull lets have it unless it's harmfull to
 other parts of D, sort of.).


I personally still think it's a bad feature because it introduces 
long-distance coupling between symbols defined in two different places, 
both distinct from the place where the statement is used! Consider:

import wyda;  // defines symbol write
import geeba; // defines struct S { ... }

void main()
{
    S s;
    with (s) {
       write(5);
    }
}

Machiavelly would jump in joy at such code. What did I achieve? I saved 
a few "s.". What did I lose? The ability so say anything, but absolutely 
anything on what the code does. If S changes, the code may compile and 
run, yet doing something completely different. The dependency is not 
between the code as seen and wyda or geeba. It's between wyda and geeba, 
intermediated by "with"! I mean, if one _planned_ to design a maximally 
damaging language feature one couldn't come up with something better. 
And for what? Because you find it convenient to not type "s." a few 
times or just go in the blessed object and define a member? Is _this_ 
what makes or breaks your productivity? And are you willing to pay the 
ability to do the feeblest reasoning about your code for that doubtful 
benefit?

This is so against every single good notion of language design, I kid 
you not I feel my blood pressure rising only as I think of it. No amount 
of "but I find it useful" can protect this awful non-feature. It should 
be taken in the back and shot in the head, no trial. Shoot the lawyer 
too if it has one.


 On a similar note, Andrei, what is this spree of removing features? Ok some
 are obviously bad, imaginary types for example, but why remove other stuff
 such as commplex and with?


TDPL is coming out. This is quite literally the last chance to shed some 
old skin. Complex as a built-in does nothing of interest to anyone 
except a cute syntax for literals that nobody uses (how many remarkable 
complex literals could you imagine?) About "with"... see above before I 
die of a heart attack.

The baroque "!<>=" operators became much more attractive since Walter 
said he's considering making them overloadable.

On the other hand new features are coming, which I believe are "good 
skin". Narrowing integral conversions will go. Walter is working on a 
very cool scheme for inferring the range of expressions that makes casts 
unnecessary in many cases. Casts are a plague not only for safe code, 
but also for generic code that wants to be scalable and change-robust. 
The ease with which C and C++ allow losing state and the drowning 

happy to see D avoid.

Final switch works with enums and forces you to handle each and every 
value of the enum. Regular switch gets ranged cases by the syntax case 
a: .. case b: (I've always thought switch would be greatly helped by that).

Static foreach might be making it too.


Andrei
May 18 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).


Kind of an odd syntax.  Why not "case a .. b:"?  Parsing issues?


 Static foreach might be making it too.


That'd be a nice addition.  Especially with __traits returning
arrays/tuples, it'd be an alternative to CTFE (shudder) or template
recursion.
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:

 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).


 
 Kind of an odd syntax.  Why not "case a .. b:"?  Parsing issues?


It's consistency. Everywhere in the language a .. b implies b is 
excluded. In a switch you want to include b. So I reflected that in the 
syntax. In fact, I confess I'm more proud than I should be about that 
little detail.


 Static foreach might be making it too.


 
 That'd be a nice addition.  Especially with __traits returning
 arrays/tuples, it'd be an alternative to CTFE (shudder) or template
 recursion.


Yah, can't wait.


Andrei
May 18 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, May 18, 2009 at 1:57 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


 of the enum. Regular switch gets ranged cases by the syntax case a: ..
 case
 b: (I've always thought switch would be greatly helped by that).


 Kind of an odd syntax. =A0Why not "case a .. b:"? =A0Parsing issues?


 It's consistency. Everywhere in the language a .. b implies b is excluded=


.

 In a switch you want to include b. So I reflected that in the syntax. In
 fact, I confess I'm more proud than I should be about that little detail.


Well after all this discussion, I think I like your syntax after all
:P  In fact, I might be inclined to use it in MiniD.  It already has
ranged cases of the form "case a .. b:" but the inconsistency between
it being inclusive and slices being inclusive has never sat well with
me.
May 18 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:

 it'd be an alternative to CTFE (shudder)


Why shudder? CTFE has familiar syntax (the syntax of the runtime 
language) and, I've found, less bugs in general.
May 18 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Mon, May 18, 2009 at 3:29 PM, Robert Fraser
<fraserofthenight gmail.com> wrote:

 Jarrett Billingsley wrote:

 it'd be an alternative to CTFE (shudder)


 Why shudder? CTFE has familiar syntax (the syntax of the runtime language)
 and, I've found, less bugs in general.


It's extremely difficult to make CTFE functions that work.  The
compiler often coughs on seemingly-legal code, sometimes due to bugs.
The biggest issue with developing CTFE functions is that if something
does go wrong during CTFE, all you get is a message along the lines of
"function X can't be evaluated at compile time", with no indication as
to _why_ it couldn't, no stack trace etc.  There's also no means of
outputting debugging statements during CTFE.  At least with templates
I have pragma(msg).

CTFE is also mainly useful for building up string mixins, but since
everything inside a CTFE function has to be code that can be executed
at runtime as well, you forgo some really useful metaprogramming
features that are native to templates, like pattern matching.  So it
ends up being convenient in simple cases (i.e. given a list of names,
generate a bunch of almost-identical declarations for them), but not
in more complex ones.

Not to mention it's much slower than template instantiation and eats
memory for lunch.
May 18 2009
parent BCS <ao pathlink.com> writes:
Reply to Jarrett,


 Not to mention it's much slower than template instantiation and eats
 memory for lunch
 


Template instantiation eats memory for breakfast lunch and dinner, plus a 
few snack in between (it adds a symbol table entry of anything you do) and 
is not much, if any, faster.
May 18 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


TDPL is coming out. This is quite literally the last chance to shed some old
skin.<


I think D2 will not fully stop evolving when TDPL is printed. I don't think D2
will be fully finished in few months.



 About "with"... see above before I die of a heart attack.<


Qualified imports are safer. And it's better for:
import foo;
to import in the current namespace only the "foo" module name.



 The baroque "!<>=" operators became much more attractive since Walter 
 said he's considering making them overloadable.


That makes them more flexible, but this doesn't make them more readable or nice
looking :-)



 Walter is working on a very cool scheme for inferring the range of expressions
that makes casts unnecessary in many cases.<


I guess all we can do is Wait and Hope then? :-)



 Final switch works with enums and forces you to handle each and every value of
the enum.<


Do you mean like this?
final switch (...) {...}



 Regular switch gets ranged cases by the syntax case a: .. case b: (I've always
thought switch would be greatly helped by that).<


Isn't a syntax like the following better?
case a .. b:
Or (much) better still, isn't it better to give a built-in syntax to something
like your iota(), removing the special syntax of ranged foreach and such ranged
switch case?

Bye,
bearophile
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Andrei Alexandrescu:

 About "with"... see above before I die of a heart attack.<


 
 Qualified imports are safer. And it's better for: import foo; to
 import in the current namespace only the "foo" module name.


Yeah, so for the sake of a feature intended to save some minor typing, 
I'm thrilled to introduce a feature requiring me a ton of typing.


 Do you mean like this? final switch (...) {...}


Yah.

enum DeviceStatus { ready, busy, fail }
...
void process(DeviceStatus status) {
    final switch (status) {
    case DeviceStatus.ready:
       ...
    case DeviceStatus.busy:
       ...
    case DeviceStatus.fail:
       ...
    }
}

If you then add a new value for DeviceStatus, the final switch won't 
compile.


 Regular switch gets ranged cases by the syntax case a: .. case b:
 (I've always thought switch would be greatly helped by that).<


 
 Isn't a syntax like the following better? case a .. b: Or (much)
 better still, isn't it better to give a built-in syntax to something
 like your iota(), removing the special syntax of ranged foreach and
 such ranged switch case?


I think it's important to give switch a crack on properly optimizing its 
code. And case a .. b I just explained to Jarrett.


Andrei
May 18 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


Yeah, so for the sake of a feature intended to save some minor typing, I'm
thrilled to introduce a feature requiring me a ton of typing.<


Please, be serious. You can have the same old behavour with just 2 added chars:
import foo.*;
I have discussed about something like this four times in the past.



 enum DeviceStatus { ready, busy, fail }
 ...
 void process(DeviceStatus status) {
     final switch (status) {
     case DeviceStatus.ready:
        ...
     case DeviceStatus.busy:
        ...
     case DeviceStatus.fail:
        ...
     }
 }
 If you then add a new value for DeviceStatus, the final switch
 won't compile.


1) I don't like this idea. I think that normal switches can behave like such
final switches.
2) I'd like Walter to ask people before implement features. People here discuss
about feature X for a week, that they think it is cool (or maybe even useful!),
and then weeks later Walter implements feature Y that no one was asking for.
This is not just wrong, it's silly.
3) If you want to add a second kind of switch, then let's add a truly safer
one, with no fall-through, etc. We have discussed about this more than one




I think it's important to give switch a crack on properly optimizing its code.<


Of course. That's why I was talking about a "built-in syntax". I am sure the
compiler doesn't need rocket science to optimize a new syntax to say the same
thing. I have done this in the ShedSkin compiler, and it's doable.



And case a .. b I just explained to Jarrett.<


1) The syntax you talk about isn't intuitive. This is bad.
2) Before introducing new syntax it's MUCH better to discuss it first, because
what's intuitive for me can be not intuitive for you. So the best you can do is
to ask for several ideas to people, and then use the one that is both logically
sound, and intuitive for most people. This is how Python syntax is designed.
And Python3 has less warts than most languages around.
3) In the past I have discussed how Ruby, Chapel and other languages solve this
problem. A solution is to use a .. #b to denote that b is inclusive. You may
not like this idea (and I am not sure I like it much), but it doesn't look so
much worse than case a: .. case b:

Thank you uncovering part of the future work of Walter, giving people 1 chance
to cach design mistakes before they happen.

Bye,
bearophile
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 2) I'd like Walter to ask people before implement features. People
 here discuss about feature X for a week, that they think it is cool
 (or maybe even useful!), and then weeks later Walter implements
 feature Y that no one was asking for. This is not just wrong, it's
 silly.


To be brutally honest, I think many features discussed here are 
completely missing the point. Only a couple of posts ago, there were 
suggestions for alternate syntaxes for "with" that were not only 
useless, they added new keywords like they were up for grabs. If 
somebody wants to make "as" into a keyword, I'm liable to go postal. 
More to the point, I forgot the exact context, but recently a poster 
wrote a long message describing how he wants simultaneously two 
completely antagonistic features, to finally (and to his credit) 
courageously face the inevitable truth: that he had no idea what he 
really wanted. This is happening a lot in this group, just that most of 
the time it goes undetected.

My perception is that the recently-added features are of good quality.


 3) In the past I have discussed how Ruby, Chapel
 and other languages solve this problem. A solution is to use a .. #b
 to denote that b is inclusive. You may not like this idea (and I am
 not sure I like it much), but it doesn't look so much worse than case
 a: .. case b:


It looks and is a million times worse. If you know D1 and see

case 'a': .. case 'z':

you pretty sure know exactly what's going on. If you know D1 but haven't 
been illuminated by the likes of Ruby and Chapel and see:



you're like, what the heck were they thinking about when they designed 
this ass-backward syntax?


Andrei
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Thank you for your answers.


To be brutally honest, I think many features discussed here are completely
missing the point.<


I know, most of the things I say are wrong or useless. I am not good at all.
Yet, no one is perfect, and in the past I/we have discussed about several
things that are badly designed in D.



Only a couple of posts ago, there were suggestions for alternate syntaxes for
"with" that were not only useless, they added new keywords like they were up
for grabs. If somebody wants to make "as" into a keyword, I'm liable to go
postal.<


That was me, and it was not a much serious proposal (I was not sure in the
first place).
But sometimes I don't like how much D relies on punctuation (like the semicolon
in the middle of foreach).
When I see a syntax like:
alias foo bar;
I often have troubles understanding if the new name is bar or foo.
A syntax like:
alias foo as bar;
Is less ambigous.
Now feel free to go postal :-)

I have even troubles to remember if in the following syntax n is the number of
rows or the number of columns:
auto mat = new[][](n, m);
Maybe I'm just dumb :-)



My perception is that the recently-added features are of good quality.<


This is probably thank to you too, because now there are two people designing
things instead of just one.



 It looks and is a million times worse. If you know D1 and see
 case 'a': .. case 'z':
 you pretty sure know exactly what's going on. If you know D1 but haven't


been illuminated by the likes of Ruby and Chapel and see:


 you're like, what the heck were they thinking about when they designed this
ass-backward syntax?


The problem with a syntax like:
case 'a': .. case 'z':
Is that it's not general enough. The language clearly needs a syntax to specify
ranges, both closed and open, that can iterated on, that support opIn_r, that
can lazily iterated, that have a length, etc. Using a .. syntax inside the
foreach, and another .. syntax inside the switch, and defining iota() into the
std lib, doesn't like a good idea to me. It howls for a general language-wide
solution.

Bye,
bearophile
May 18 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
bearophile wrote:

 I am not good at all.


*shares some prozac*
May 18 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:

 bearophile wrote:

 I am not good at all.


 
 *shares some prozac*


I'll have some too. I didn't mean to put bearophile or anyone down more 
than myself. The crude reality is that D does not have any real 
programming language expert on board. We are trying to do the best with 
what we have.

Andrei
May 18 2009
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:guscb3$2iqj$1 digitalmars.com...

 I have even troubles to remember if in the following syntax n is the 
 number of rows or the number of columns:
 auto mat = new[][](n, m);


That's just a matter of convention. Neither is inherently a row or a column.
May 18 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
bearophile wrote:

 When I see a syntax like:
 alias foo bar;
 I often have troubles understanding if the new name is bar or foo.
 A syntax like:
 alias foo as bar;
 Is less ambigous.
 Now feel free to go postal :-)


The more common suggestion is:
alias bar = foo;

This has the advantage of looking like renamed imports and not adding 

using Name=My.Really.Long.Namespace.CollidingName;
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


This is acceptable, thank you :-)
Now I'd like to know what others think about that.

Bye,
bearophile
May 18 2009
next sibling parent div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bearophile wrote:

 Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


 
 This is acceptable, thank you :-)
 Now I'd like to know what others think about that.
 
 Bye,
 bearophile


That's rather nice. Would make coding after a few beers easier.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKEe/FT9LetA9XoXwRAoCuAJ9ns6O5kEMXVftt6GZP26wNTpCJxACgiSaN
Q4ClZbiH5vGmlFHpBPnsSuc=
=hJnG
-----END PGP SIGNATURE-----
May 18 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


 
 This is acceptable, thank you :-)
 Now I'd like to know what others think about that.
 
 Bye,
 bearophile


I'd love that.

Andrei
May 18 2009
prev sibling next sibling parent Christopher Wright <dhasenan gmail.com> writes:
bearophile wrote:

 Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


 
 This is acceptable, thank you :-)
 Now I'd like to know what others think about that.
 
 Bye,
 bearophile


Why thank me? It's been batted around a few times, and it was not my 
suggestion originally.
May 18 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote:


 Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


 
 This is acceptable, thank you :-)
 Now I'd like to know what others think about that.


But does that mean 'when I write "bar" I really mean "foo"' or visa versa?

Just pointing out that the '=' sign doesn't really automatically make it
fully intuitive.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:2m4gnylh4ggc.1hhjynllwweim.dlg 40tude.net...

 On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote:


 Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


 This is acceptable, thank you :-)
 Now I'd like to know what others think about that.


 But does that mean 'when I write "bar" I really mean "foo"' or visa versa?

 Just pointing out that the '=' sign doesn't really automatically make it
 fully intuitive.


It makes it consistent with "auto foo = bar;" which is a big improvement in 
intuitiveness.
May 19 2009
parent Chris Mueller <ruun.net googlemail.com> writes:
Nick Sabalausky schrieb:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:2m4gnylh4ggc.1hhjynllwweim.dlg 40tude.net...

 On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote:


 Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


 This is acceptable, thank you :-)
 Now I'd like to know what others think about that.


 But does that mean 'when I write "bar" I really mean "foo"' or visa versa?

 Just pointing out that the '=' sign doesn't really automatically make it
 fully intuitive.


 
 It makes it consistent with "auto foo = bar;" which is a big improvement in 
 intuitiveness. 
 
 


I would also welcome this change. Like someone here already mentioned 
it's also consistent with renaming imports, which has the same syntax.

import io = std.stdio;


Chris
May 18 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 19:24:13 -0400, bearophile wrote:
 

 Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


 This is acceptable, thank you :-)
 Now I'd like to know what others think about that.


 
 But does that mean 'when I write "bar" I really mean "foo"' or visa versa?
 
 Just pointing out that the '=' sign doesn't really automatically make it
 fully intuitive.


It would work like assignments and renamed imports. Since when did you 
make an assignment in D where the right hand side was modified according 
to the value of the left hand side?

It's not immediately obvious to someone who hasn't programmed yet, 
necessarily, but to someone even vaguely familiar with any modern 
programming language, there is one obvious meaning.
May 19 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


I can add this too:
typedef Bar = Foo;

This changes in typedef and alias can solve two of the small problems I have
with D. Let's see if Walter accepts such ideas.

(In the last days two more ideas have floated in this newsgroup: disallowing
floating point literals with nothing before the point like ".57", and making
"with" safer). Such small improvements pile up.

Bye,
bearophile
May 20 2009
parent KennyTM~ <kennytm gmail.com> writes:
bearophile wrote:

 Christopher Wright:

 The more common suggestion is:
 alias bar = foo;


 
 I can add this too:
 typedef Bar = Foo;
 
 This changes in typedef and alias can solve two of the small problems I have
with D. Let's see if Walter accepts such ideas.
 
 (In the last days two more ideas have floated in this newsgroup: disallowing
floating point literals with nothing before the point like ".57", and making
"with" safer). Such small improvements pile up.
 
 Bye,
 bearophile


typedef int MyInt = 1;
May 20 2009
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Andrei Alexandrescu wrote:

 To be brutally honest, I think many features discussed here are 
 completely missing the point. Only a couple of posts ago, there were 
 suggestions for alternate syntaxes for "with" that were not only 
 useless, they added new keywords like they were up for grabs. If 
 somebody wants to make "as" into a keyword, I'm liable to go postal. 
 More to the point, I forgot the exact context, but recently a poster 
 wrote a long message describing how he wants simultaneously two 
 completely antagonistic features, to finally (and to his credit) 
 courageously face the inevitable truth: that he had no idea what he 
 really wanted. This is happening a lot in this group, just that most of 
 the time it goes undetected.
 



 Andrei


we don't need any new syntax to get rid of with.
most of the time you use it like (for example):

for (int i = 0; i < 10; ++i) {
   with (myLongVar[i].myLongMember.MylongOtherMember) {
     myLongMethod();
   }
}

so why not allow:
for (int i = 0; i < 10; ++i) {
   alias myLongVar[i].myLongMember.MylongOtherMember tempSymbol;
   tempSymbol.myLongMethod();
}

this doesn't add any new syntax
May 18 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 14:33:29 -0400, bearophile wrote:


 3) If you want to add a second kind of switch, then let's
    add a truly safer one, with no fall-through, etc.


**WARNING** an off-topic aside follows ...

The next version of the Euphoria programming language has implemented
'switch'. The language only had 'if-elsif-' constructs before. The new
'switch' has this syntax ...

   'switch' ['with fallthru'] 'do'
       'case' EXPRESSION 'then'
           STATEMENTS
           [( 'break' | 'fallthru')]
       . . .
   'end' 'switch'

Yeah, I know is not a punctuation-heavy language like D, but get over that
for now. The point is that by default the cases do not fallthru. If you
want cases to fallthru by default you need to add the 'with fallthru'
qualifier. Furthermore, each case can have 'break' to explicitly prevent it
falling thru to the next case, or 'fallthru' to explicitly cause it to fall
thru to the next case. If you have neither, then it does the default action
indicated on the 'switch' line.

procedure classify(char c)
    write("You passed ")
    switch c do

          writeln("a hash sign.")

       case in "012345679" then
          writeln("a digit.")

       case 'A' to 'Z', 'a' to 'z' then
          writeln("an ASCII character.")

       case '.', ',', ':', ';', '!', '?' then
          writeln("a punctuation mark.")

       case else
          writeln("quite a character!")

    end switch
end procedure

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 10:46 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Johan Granberg wrote:

 BCS wrote:


 Hello Andrei,


 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
 y +=3D x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.


 I'd be willing to go the half way solution of making accessing a
 shadowing
 symbol an error, resulting in (loudly) not being able to access either.


 I think this solution is a good idea but that removing or restricting
 anything more regarding with is a bad idea as others have pointed out.

 I'm using with quit a lot and it was one of thous things that attracted =




me

 to D (I get the feeling that D has a quite pragmatic way of looking at
 language features, if it's usefull lets have it unless it's harmfull to
 other parts of D, sort of.).


 I personally still think it's a bad feature because it introduces
 long-distance coupling between symbols defined in two different places, b=


oth

 distinct from the place where the statement is used! Consider:

 import wyda; =A0// defines symbol write
 import geeba; // defines struct S { ... }

 void main()
 {
 =A0 S s;
 =A0 with (s) {
 =A0 =A0 =A0write(5);
 =A0 }
 }

 Machiavelly would jump in joy at such code. What did I achieve? I saved a
 few "s.". What did I lose? The ability so say anything, but absolutely
 anything on what the code does.


Shouldn't the feature just follow the same rules as module imports do?

If I say
  import foo;
  import bar;
  void main() {
      write(5);
  }

It's fine as long as foo and bar don't both define bar.  Why shouldn't
the same scope resolution mechanism not apply to with?

So in your example write(5) is fine as long as S and some module don't
both define a write().

I think that's what others were saying in the other thread, too.
Makes things more consistent too.   Given that do you still object to
with() so vehemently?

--bb






If S changes, the code may compile and run,

 yet doing something completely different. The dependency is not between t=


he

 code as seen and wyda or geeba. It's between wyda and geeba, intermediate=


d

 by "with"! I mean, if one _planned_ to design a maximally damaging langua=


ge

 feature one couldn't come up with something better. And for what? Because
 you find it convenient to not type "s." a few times or just go in the
 blessed object and define a member? Is _this_ what makes or breaks your
 productivity? And are you willing to pay the ability to do the feeblest
 reasoning about your code for that doubtful benefit?

 This is so against every single good notion of language design, I kid you
 not I feel my blood pressure rising only as I think of it. No amount of "=


but

 I find it useful" can protect this awful non-feature. It should be taken =


in

 the back and shot in the head, no trial. Shoot the lawyer too if it has o=


ne.

 On a similar note, Andrei, what is this spree of removing features? Ok
 some
 are obviously bad, imaginary types for example, but why remove other stu=




ff

 such as commplex and with?


 TDPL is coming out. This is quite literally the last chance to shed some =


old

 skin. Complex as a built-in does nothing of interest to anyone except a c=


ute

 syntax for literals that nobody uses (how many remarkable complex literal=


s

 could you imagine?) About "with"... see above before I die of a heart
 attack.

 The baroque "!<>=3D" operators became much more attractive since Walter s=


aid

 he's considering making them overloadable.

 On the other hand new features are coming, which I believe are "good skin=


".

 Narrowing integral conversions will go. Walter is working on a very cool
 scheme for inferring the range of expressions that makes casts unnecessar=


y

 in many cases. Casts are a plague not only for safe code, but also for
 generic code that wants to be scalable and change-robust. The ease with
 which C and C++ allow losing state and the drowning necessity of integral


 Final switch works with enums and forces you to handle each and every val=


ue

 of the enum. Regular switch gets ranged cases by the syntax case a: .. ca=


se

 b: (I've always thought switch would be greatly helped by that).

 Static foreach might be making it too.


 Andrei
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, May 18, 2009 at 10:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Johan Granberg wrote:

 BCS wrote:


 Hello Andrei,


 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.


 I'd be willing to go the half way solution of making accessing a
 shadowing
 symbol an error, resulting in (loudly) not being able to access either.


 I think this solution is a good idea but that removing or restricting
 anything more regarding with is a bad idea as others have pointed out.

 I'm using with quit a lot and it was one of thous things that attracted me
 to D (I get the feeling that D has a quite pragmatic way of looking at
 language features, if it's usefull lets have it unless it's harmfull to
 other parts of D, sort of.).


 I personally still think it's a bad feature because it introduces
 long-distance coupling between symbols defined in two different places, both
 distinct from the place where the statement is used! Consider:

 import wyda;  // defines symbol write
 import geeba; // defines struct S { ... }

 void main()
 {
   S s;
   with (s) {
      write(5);
   }
 }

 Machiavelly would jump in joy at such code. What did I achieve? I saved a
 few "s.". What did I lose? The ability so say anything, but absolutely
 anything on what the code does.


 
 Shouldn't the feature just follow the same rules as module imports do?
 
 If I say
   import foo;
   import bar;
   void main() {
       write(5);
   }
 
 It's fine as long as foo and bar don't both define bar.  Why shouldn't
 the same scope resolution mechanism not apply to with?
 
 So in your example write(5) is fine as long as S and some module don't
 both define a write().
 
 I think that's what others were saying in the other thread, too.
 Makes things more consistent too.   Given that do you still object to
 with() so vehemently?


I'd be happy if "with" were consistent in the way you describe. Nice idea!

Andrei
May 18 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 10:46 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Johan Granberg wrote:

 BCS wrote:


 Hello Andrei,


 I think "with" is a very dangerous feature due to the way it hides
 symbols. It essentially makes the feeblest attempt at modular
 reasoning utterly impossible:

 int x, y;
 with (whatever)
 {
 y += x;
 ++x;
 }

 Maintenance of any type that is being used with "with" becomes a very
 dangerous proposition because it can silently change meaning of code.


 I'd be willing to go the half way solution of making accessing a
 shadowing
 symbol an error, resulting in (loudly) not being able to access 
 either.


 I think this solution is a good idea but that removing or restricting
 anything more regarding with is a bad idea as others have pointed out.

 I'm using with quit a lot and it was one of thous things that 
 attracted me
 to D (I get the feeling that D has a quite pragmatic way of looking at
 language features, if it's usefull lets have it unless it's harmfull to
 other parts of D, sort of.).


 I personally still think it's a bad feature because it introduces
 long-distance coupling between symbols defined in two different 
 places, both
 distinct from the place where the statement is used! Consider:

 import wyda;  // defines symbol write
 import geeba; // defines struct S { ... }

 void main()
 {
   S s;
   with (s) {
      write(5);
   }
 }

 Machiavelly would jump in joy at such code. What did I achieve? I 
 saved a
 few "s.". What did I lose? The ability so say anything, but absolutely
 anything on what the code does.


 Shouldn't the feature just follow the same rules as module imports do?

 If I say
   import foo;
   import bar;
   void main() {
       write(5);
   }

 It's fine as long as foo and bar don't both define bar.  Why shouldn't
 the same scope resolution mechanism not apply to with?

 So in your example write(5) is fine as long as S and some module don't
 both define a write().

 I think that's what others were saying in the other thread, too.
 Makes things more consistent too.   Given that do you still object to
 with() so vehemently?


 
 I'd be happy if "with" were consistent in the way you describe. Nice idea!



Then we could have "an implicit with" in effect all the time!

I.e., every time i use 'write', and there's no ambiguity, I wouldn't 
have to write foo.write or bar.write. Saves a lot of ink! Yessss. And 
this should not be hard to implement at all.



Except that code would then become hard to analyze.

End result: using 's.' really isn't such a bad alternative.
May 18 2009
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 Jarrett Billingsley wrote:

 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 

 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).


 
 Kind of an odd syntax.  Why not "case a .. b:"?  Parsing issues?


 
 It's consistency. Everywhere in the language a .. b implies b is 
 excluded. In a switch you want to include b. So I reflected that in the 
 syntax. In fact, I confess I'm more proud than I should be about that 
 little detail.


Consistency???

While I can see where you're coming from, I still see plenty of
inconsistencies. It's still a range (defined with .. too). Having slices and
foreach use syntax a and meaning 1 but switch using syntax a' and meaning 2
kind of sucks. 
 
 

 Static foreach might be making it too.


 
 That'd be a nice addition.  Especially with __traits returning
 arrays/tuples, it'd be an alternative to CTFE (shudder) or template
 recursion.


 
 Yah, can't wait.


I'm still hoping for static switch too!
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 Andrei Alexandrescu Wrote:
 

 Jarrett Billingsley wrote:

 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).


 Kind of an odd syntax.  Why not "case a .. b:"?  Parsing issues?


 It's consistency. Everywhere in the language a .. b implies b is 
 excluded. In a switch you want to include b. So I reflected that in the 
 syntax. In fact, I confess I'm more proud than I should be about that 
 little detail.


 
 Consistency???
 
 While I can see where you're coming from, I still see plenty of
inconsistencies. It's still a range (defined with .. too). Having slices and
foreach use syntax a and meaning 1 but switch using syntax a' and meaning 2
kind of sucks. 


You'd have to squint real hard to see a range. A range is

expr1 .. expr2

That code is

case expr1: .. case expr2:

I mean you can't tell me that as soon as ".." is within a mile it's a range.


Andrei
May 18 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 Jason House wrote:

 Andrei Alexandrescu Wrote:
 

 Jarrett Billingsley wrote:

 On Mon, May 18, 2009 at 1:46 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 Final switch works with enums and forces you to handle each and every value
 of the enum. Regular switch gets ranged cases by the syntax case a: .. case
 b: (I've always thought switch would be greatly helped by that).


 Kind of an odd syntax.  Why not "case a .. b:"?  Parsing issues?


 It's consistency. Everywhere in the language a .. b implies b is 
 excluded. In a switch you want to include b. So I reflected that in the 
 syntax. In fact, I confess I'm more proud than I should be about that 
 little detail.


 
 Consistency???
 
 While I can see where you're coming from, I still see plenty of
inconsistencies. It's still a range (defined with .. too). Having slices and
foreach use syntax a and meaning 1 but switch using syntax a' and meaning 2
kind of sucks. 


 
 You'd have to squint real hard to see a range. A range is
 
 expr1 .. expr2
 
 That code is
 
 case expr1: .. case expr2:
 
 I mean you can't tell me that as soon as ".." is within a mile it's a range.
 
 
 Andrei


It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.
May 18 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 3:29 PM, Jason House
<jason.james.house gmail.com> wrote:


 It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.


Agreed.  If you tell someone   a .. b  means a non-inclusive range
from a to b, then ask them to guess what    blarf a .. blarf b  means,
I would be very surprised if many guessed "inclusive range from blarf
a  to blarf b".

... Unless they guess that the fact you were asking something which
should be so obvious meant that it was probably a trick question, in
which case they'd answer inclusive, that being the non-obvious answer.

--bb
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".


Thank you for nicely expressing one of the critics I was trying to express.
(My other problem is that I'd like a more general syntax).

------------------------

A different simple solution can be:
case a .. b+1:
That requires no new syntax.

Bye,
bearophile
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Bill Baxter:

 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".


 
 Thank you for nicely expressing one of the critics I was trying to express.
 (My other problem is that I'd like a more general syntax).
 
 ------------------------
 
 A different simple solution can be:
 case a .. b+1:
 That requires no new syntax.
 
 Bye,
 bearophile


void classify(char c) {
    write("You passed ");
    switch (c) {

          writeln("a hash sign.");
          break;
       case '0' .. case '9':
          writeln("a digit.");
          break;
       case 'A' .. case 'Z': case 'a' .. case 'z':
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}

Cool!

void classify(char c) {
    write("You passed ");
    switch (c) {

          writeln("a hash sign.");
          break;
       case '0' .. '9'+1:
          writeln("a digit.");
          break;
       case 'A' .. 'Z'+1: case 'a' .. 'z'+1:
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}

Awful!


Andrei
May 18 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

Thank you for bringing a "real" example that gives something to work on.


Awful!<


Well, one of your cases was wrong. Using the +1 at the end one of those cases
become:
case 'A' .. 'Z'+1, 'a' .. 'z'+1:
Instead of what you have written:
case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

I agree that that syntax with +1 isn't very nice looking. But the advantage of
+1 is that it introduces (almost) no new syntax, it's not easy to miss, its
meaning is easy to understand. AND you don't have to remember that in a case
the .. is inclusive while in foreach is exclusive on the right, keeping the
standard way in D to denote ranges.

-------------------------

We can introduce in D a syntax that maps on the semantics of iota(start, stop)
or even iota(start, stop, step) (I don't remember if iota() supports opIn_r,
and has length, if not then it's better to add them).

So you can do:

foreach (i; somerangesyntax) {...}
(So this replaces the current ranged foreach syntax).

case somerangesyntax: ...

if (x in somerangesyntax) {...}

map(fun, somerangesyntax);

And more, using only one (or two) general syntaxes.

-------------------------

The simple exclusive range syntax, with +1:

void classify(char c) {
    write("You passed ");
    switch (c) {

          writeln("a hash sign.");
          break;
       case '0' .. '9'+1:
          writeln("a digit.");
          break;
       case 'A' .. 'Z'+1, 'a' .. 'z'+1:
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


Using Chapel closed range syntax:

void classify(char c) {
    write("You passed ");
    switch (c) {

          writeln("a hash sign.");
          break;

          writeln("a digit.");
          break;

          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


An alternative to that Chapel syntax:

void classify(char c) {
    write("You passed ");
    switch (c) {

          writeln("a hash sign.");
          break;
       case '0' ..> '9':
          writeln("a digit.");
          break;
       case 'A' ..> 'Z', 'a' ..> 'z':
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


It may be easy to miss the third point (but it's not a noisy syntax)

void classify(char c) {
    write("You passed ");
    switch (c) {

          writeln("a hash sign.");
          break;
       case '0' ... '9':
          writeln("a digit.");
          break;
       case 'A' ... 'Z', 'a' ... 'z':
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


Using something more explicit (interval() is lazy and inclusive on the right.
The D compiler optimizes away at compile time the following calls):

void classify(char c) {
    write("You passed ");
    switch (c) {

          writeln("a hash sign.");
          break;
       case interval('0', '9'):
          writeln("a digit.");
          break;
       case interval('A', 'Z'), interval('a', 'z'):
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}


void classify(char c) {
    write("You passed ");
    switch (c) {

          writeln("a hash sign.");
          break;
       case ['0' .. '9']:
          writeln("a digit.");
          break;
       case ['A' .. 'Z'], ['a' .. 'z']:
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
    }
}



Such syntaxes are meant to be used in every other situation too (and I'd like
to have another syntax that is non-inclusive, possibly like the current one):

foreach (i; 'A' .. 'Z'+1) {...}
case 'A' .. 'Z'+1: ...
if (x in 'A' .. 'Z'+1) {...}
map(fun, 'A' .. 'Z'+1);






foreach (i; 'A' ..> 'Z') {...}
case 'A' ..> 'Z': ...
if (x in 'A' ..> 'Z') {...}
map(fun, 'A' ..> 'Z');

foreach (i; 'A' ... 'Z') {...}
case 'A' ... 'Z': ...
if (x in 'A' ... 'Z') {...}
map(fun, 'A' ... 'Z');

foreach (i; interval('A', 'Z')) {...}
case interval('A', 'Z'): ...
if (x in interval('A', 'Z')) {...}
map(fun, interval('A', 'Z'));

foreach (i; ['A' .. 'Z']) {...}
case ['A' .. 'Z']: ...
if (x in ['A' .. 'Z']) {...}
map(fun, ['A' .. 'Z']);


The a..b+1 syntax can't be used inside map() in a simple way.

The [a .. b] syntax is acceptable, but then it doesn't offer a good way to
define those if() and map() for the noninclusive situation:

// inclusive cases?
foreach (i; ['A' .. 'Z']) {...}
case ['A' .. 'Z']: ...
if (x in ['A' .. 'Z']) {...}
map(fun, ['A' .. 'Z']);

// noninclusive cases?
foreach (i; 'A' .. 'Z') {...}
case 'A' .. 'Z': ...
if (x in 'A' .. 'Z') {...}
map(fun, 'A' .. 'Z');

Well... That's not perfect, but it looks better than the syntax suggested by
Andrei. Do you have better ideas?

Bye,
bearophile
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Andrei Alexandrescu:
 
 Thank you for bringing a "real" example that gives something to work on.
 

 Awful!<


 
 Well, one of your cases was wrong. Using the +1 at the end one of those cases
become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:
 
 I agree that that syntax with +1 isn't very nice looking. But the advantage of
+1 is that it introduces (almost) no new syntax, it's not easy to miss, its
meaning is easy to understand. AND you don't have to remember that in a case
the .. is inclusive while in foreach is exclusive on the right, keeping the
standard way in D to denote ranges.


You don't understand. My point is not that people will dislike 'Z'+1. 
They will FORGET TO WRITE THE BLESSED +1. They'll write:

case 'A' .. 'Z':

and they'll wonder why the hell Z is not handled. Now do you see why 
it's sometimes ungainly to discuss language design here? It can only go 
forever, and in the end anyone can say "but I just don't like it". In 
fact I'll use that prerogative right now:

[snip]


 Well... That's not perfect, but it looks better than the syntax suggested by
Andrei. Do you have better ideas?


I like my syntax better than all you mentioned, by a mile.


Andrei
May 18 2009
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:


 I like my syntax better than all you mentioned, by a mile.


Problem: Define a syntax that indicates a specific range of values for a
single case statement.

Constraints:
(1) No new keywords permitted.
(2) No new operators permitted.
(3) Must indicate an *inclusive* range
(4) A range has an explicit starting value and ending value
(5) A range has an implicit step value of 1.
(6) Must not be keystroke-heavy
(7) Must be easy to read
(8) Must be easy to remember while writing
(9) Must not be ambiguous with existing syntax
(10) Must be consistent with existing syntax
(11) Must take the general form ...

    'case' RANGE ':'


Andrei ...
  case FIRST .. case LAST :
   [[ -(8)- The second 'case' is easy to forget to write ]]
   [[ -(10)- The ".." means exclusive range elsewhere but not here ]]

bearophile ...
  case FIRST .. LAST+1 :
   [[ -(8)- The +1 is easy to forget to write ]]

JB (first pass)
  case FIRST .. LAST :
   [[ -(10)- inconsistent with exclusive range syntax]]


So just as a thought without a lot of adademic introspection 

derek ...
  case [FIRST ; LAST] :

  sample code ...
    void classify(char c) {
      write("You passed ");
      switch (c) {

          writeln("a hash sign.");
          break;
       case ['0' ; '9']:
          writeln("a digit.");
          break;
       case ['A' ; 'Z'], ['a' ; 'z']:
          writeln("an ASCII character.");
          break;
       case '.', ',', ':', ';', '!', '?':
          writeln("a punctuation mark.");
          break;
       default:
          writeln("quite a character!");
          break;
      }
  }

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:
 

 I like my syntax better than all you mentioned, by a mile.


 
 Problem: Define a syntax that indicates a specific range of values for a
 single case statement.
 
 Constraints:


(0) Must be recognizable and understood at first sight without the user 
running to the manual and looking it up.


 (1) No new keywords permitted.
 (2) No new operators permitted.
 (3) Must indicate an *inclusive* range
 (4) A range has an explicit starting value and ending value
 (5) A range has an implicit step value of 1.
 (6) Must not be keystroke-heavy
 (7) Must be easy to read
 (8) Must be easy to remember while writing
 (9) Must not be ambiguous with existing syntax
 (10) Must be consistent with existing syntax
 (11) Must take the general form ...
 
     'case' RANGE ':'
 
 
 Andrei ...
   case FIRST .. case LAST :
    [[ -(8)- The second 'case' is easy to forget to write ]]


Compile-time error.


    [[ -(10)- The ".." means exclusive range elsewhere but not here ]]


NO. NO. NO. BY GOLLY NO. Please understand the very basics of a grammar. 
I swear this is the last time I explain that.

".." is a TOKEN. TOKEN. TOKEN. Punctuation. It is NOT any grammatical 
construct in particular.

expression1 .. expression2

is a notation for ranges. All elements must be present. ".." by itself 
does not have a meaning.

case expression1: .. case expression2:

is an entirely different construct. It does not have expression1 .. 
expression2 anywhere in sight. It is ridiculous to attribute meaning to 
".." alone as much as saying that "(" must only used to initiate a 
function call or "[" must be only used to initiate an array indexing 
operation.


 bearophile ...
   case FIRST .. LAST+1 :
    [[ -(8)- The +1 is easy to forget to write ]]
 
 JB (first pass)
   case FIRST .. LAST :
    [[ -(10)- inconsistent with exclusive range syntax]]
 So just as a thought without a lot of adademic introspection 
 
 derek ...
   case [FIRST ; LAST] :


Fails (0) with flying colors.


Andrei
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gut7lb$ue8$1 digitalmars.com...

 (0) Must be recognizable and understood at first sight without the user 
 running to the manual and looking it up.


I've never considered that a particularly good criterea in most cases. Most 
language features/syntax are non-obvious at a glance for anyone who isn't 
already familiar with it. And typically, you only need to look it up once 
and then next time you see it you'll remember. People had the same complaint 
when '$' was proposed for blah.length, but seriously, one it was included 
who here has ever had a non-trivial time learning and internalizing that? 
Does '!()' scream "template" to someone who hasn't used D or looked at the D 
docs? Of course not. But it works fine. And I sure someone could have easily 

whenever those were first created. But who ever has any real trouble with 
that? I didn't even the very first time I was introduced to it. This '(0)' 
is barely an issue at all.
May 19 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gut7lb$ue8$1 digitalmars.com...

 (0) Must be recognizable and understood at first sight without the user 
 running to the manual and looking it up.


 
 I've never considered that a particularly good criterea in most cases. Most 
 language features/syntax are non-obvious at a glance for anyone who isn't 
 already familiar with it.


Not slight departures from existing syntax.

Andrei
May 19 2009
prev sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Derek Parnell Wrote:


 On Mon, 18 May 2009 19:38:05 -0500, Andrei Alexandrescu wrote:
 

 I like my syntax better than all you mentioned, by a mile.


 
 Problem: Define a syntax that indicates a specific range of values for a
 single case statement.
 
 Constraints:
 (1) No new keywords permitted.
 (2) No new operators permitted.
 (3) Must indicate an *inclusive* range
 (4) A range has an explicit starting value and ending value
 (5) A range has an implicit step value of 1.
 (6) Must not be keystroke-heavy
 (7) Must be easy to read
 (8) Must be easy to remember while writing
 (9) Must not be ambiguous with existing syntax
 (10) Must be consistent with existing syntax
 (11) Must take the general form ...
 
     'case' RANGE ':'
 
 
 Andrei ...
   case FIRST .. case LAST :
    [[ -(8)- The second 'case' is easy to forget to write ]]
    [[ -(10)- The ".." means exclusive range elsewhere but not here ]]
 
 bearophile ...
   case FIRST .. LAST+1 :
    [[ -(8)- The +1 is easy to forget to write ]]
 
 JB (first pass)
   case FIRST .. LAST :
    [[ -(10)- inconsistent with exclusive range syntax]]
 
 
 So just as a thought without a lot of adademic introspection 
 
 derek ...
   case [FIRST ; LAST] :


Personally I feel that your syntax breaks the condition
(6) Must not be keystroke-heavy

I like Andei's syntax best but as previously stated, its ambiguous with
exclusive ranges.

Maybe the solution is a second range operator that is inclusive, such as:
    case FIRST ... LAST:

I don't feel it breaks the no new operator rule as ... is already handled by
the lexer, and it is obvious to the parser what the intended usage is. Also the
operator can be generalized to all range statements.

Jeremie
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:15:17 -0400, Jeremie Pelletier wrote:


 Derek Parnell Wrote:

   case [FIRST ; LAST] :


 
 Personally I feel that your syntax breaks the condition
 (6) Must not be keystroke-heavy


Huh?? By keystroke-heavy I meant the number of keyboard presses the finger
would have to do to write it.


Ignoring FIRST/LAST, I have 3 (three) keystrokes  and Andrei has 8
keystrokes? 

Me =  [ ; ]

Andrei = SHIFT : .. case


 I like Andei's syntax best but as previously stated, its ambiguous with
exclusive ranges.
 
 Maybe the solution is a second range operator that is inclusive, such as:
     case FIRST ... LAST:


Which is 3 keystrokes too. 

Sorry, I don't understand what you mean by saying my suggestion breaks (6).

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
Derek Parnell Wrote:


 On Mon, 18 May 2009 23:15:17 -0400, Jeremie Pelletier wrote:
 

 Derek Parnell Wrote:

   case [FIRST ; LAST] :


 
 Personally I feel that your syntax breaks the condition
 (6) Must not be keystroke-heavy


 
 Huh?? By keystroke-heavy I meant the number of keyboard presses the finger
 would have to do to write it.
 
 
 Ignoring FIRST/LAST, I have 3 (three) keystrokes  and Andrei has 8
 keystrokes? 
 
 Me =  [ ; ]
 
 Andrei = SHIFT : .. case
 

 I like Andei's syntax best but as previously stated, its ambiguous with
exclusive ranges.
 
 Maybe the solution is a second range operator that is inclusive, such as:
     case FIRST ... LAST:


 
 Which is 3 keystrokes too. 
 
 Sorry, I don't understand what you mean by saying my suggestion breaks (6).
 
 -- 
 Derek Parnell
 Melbourne, Australia
 skype: derek.j.parnell


Ah yes if you go by the count of characters, then yes you are right. I assumed
it meant the ease of typing it, as ... is way faster to get on the screen than
[;]. Also your characters are only easily accessible on a keyboard using the US
layout (I began programming on a french canadian layout, and you need to use
the right alt key for both [ and ], real annoying).
May 18 2009
prev sibling parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work on.


 Awful!<


 Well, one of your cases was wrong. Using the +1 at the end one of 
 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the 
 advantage of +1 is that it introduces (almost) no new syntax, it's not 
 easy to miss, its meaning is easy to understand. AND you don't have to 
 remember that in a case the .. is inclusive while in foreach is 
 exclusive on the right, keeping the standard way in D to denote ranges.


 
 You don't understand. My point is not that people will dislike 'Z'+1. 
 They will FORGET TO WRITE THE BLESSED +1. They'll write:
 
 case 'A' .. 'Z':


You know, Ruby solves this by introducing a “seperate” range syntax for 
exclusive ranges: “...”. An inclusive range is written the same as an 
exclusive range in D: “..”.




I see no reason not to include such a seperate syntax in D. “..” being 
exclusive and “...” being inclusive, not the other way round as in Ruby 
— see “Programmer’s Paradox”   
http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

Kind regards, Alex
May 19 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 19 May 2009 16:19:32 +0400, Alexander Pánek
<alexander.panek brainsware.org> wrote:


 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work  
 on.


 Awful!<


 Well, one of your cases was wrong. Using the +1 at the end one of  
 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the  
 advantage of +1 is that it introduces (almost) no new syntax, it's not  
 easy to miss, its meaning is easy to understand. AND you don't have to  
 remember that in a case the .. is inclusive while in foreach is  
 exclusive on the right, keeping the standard way in D to denote ranges.


  You don't understand. My point is not that people will dislike 'Z'+1.  
 They will FORGET TO WRITE THE BLESSED +1. They'll write:
  case 'A' .. 'Z':


 You know, Ruby solves this by introducing a “seperate” range syntax for  
 exclusive ranges: “...”. An inclusive range is written the same as an  
 exclusive range in D: “..”.




 I see no reason not to include such a seperate syntax in D. “..” being  
 exclusive and “...” being inclusive, not the other way round as in Ruby  
 — see “Programmer’s Paradox”    
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

 Kind regards, Alex


I think this is reasonable.

++vote;
May 19 2009
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Alexander Pánek schrieb:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work on.


 Awful!<


 Well, one of your cases was wrong. Using the +1 at the end one of
 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the
 advantage of +1 is that it introduces (almost) no new syntax, it's
 not easy to miss, its meaning is easy to understand. AND you don't
 have to remember that in a case the .. is inclusive while in foreach
 is exclusive on the right, keeping the standard way in D to denote
 ranges.


 You don't understand. My point is not that people will dislike 'Z'+1.
 They will FORGET TO WRITE THE BLESSED +1. They'll write:

 case 'A' .. 'Z':


 
 You know, Ruby solves this by introducing a “seperate” range syntax for
 exclusive ranges: “...”. An inclusive range is written the same as an
 exclusive range in D: “..”.
 


 
 I see no reason not to include such a seperate syntax in D. “..” being
 exclusive and “...” being inclusive, not the other way round as in Ruby
 — see “Programmer’s Paradox”  
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .
 
 Kind regards, Alex


Yes, this is useful for all use cases of ranges.
I like '...'.
May 19 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Frank Benoit wrote:

 Alexander Pánek schrieb:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to work on.


 Awful!<


 Well, one of your cases was wrong. Using the +1 at the end one of
 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the
 advantage of +1 is that it introduces (almost) no new syntax, it's
 not easy to miss, its meaning is easy to understand. AND you don't
 have to remember that in a case the .. is inclusive while in foreach
 is exclusive on the right, keeping the standard way in D to denote
 ranges.


 You don't understand. My point is not that people will dislike 'Z'+1.
 They will FORGET TO WRITE THE BLESSED +1. They'll write:

 case 'A' .. 'Z':


 You know, Ruby solves this by introducing a “seperate” range syntax for
 exclusive ranges: “...”. An inclusive range is written the same as an
 exclusive range in D: “..”.




 I see no reason not to include such a seperate syntax in D. “..” being
 exclusive and “...” being inclusive, not the other way round as in Ruby
 — see “Programmer’s Paradox”  
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

 Kind regards, Alex


 
 Yes, this is useful for all use cases of ranges.
 I like '...'.


Indeed it's not a bad idea... But it might be easily mistyped, lead to 
strange off-by-one errors and be very difficult to find while debugging 
them. Hmmm...
May 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:

 Frank Benoit wrote:

 Alexander Pánek schrieb:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to 
 work on.


 Awful!<


 Well, one of your cases was wrong. Using the +1 at the end one of
 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the
 advantage of +1 is that it introduces (almost) no new syntax, it's
 not easy to miss, its meaning is easy to understand. AND you don't
 have to remember that in a case the .. is inclusive while in foreach
 is exclusive on the right, keeping the standard way in D to denote
 ranges.


 You don't understand. My point is not that people will dislike 'Z'+1.
 They will FORGET TO WRITE THE BLESSED +1. They'll write:

 case 'A' .. 'Z':


 You know, Ruby solves this by introducing a “seperate” range syntax for
 exclusive ranges: “...”. An inclusive range is written the same as an
 exclusive range in D: “..”.




 I see no reason not to include such a seperate syntax in D. “..” being
 exclusive and “...” being inclusive, not the other way round as in Ruby
 — see “Programmer’s Paradox”  
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

 Kind regards, Alex


 Yes, this is useful for all use cases of ranges.
 I like '...'.


 
 Indeed it's not a bad idea... But it might be easily mistyped, lead to 
 strange off-by-one errors and be very difficult to find while debugging 
 them. Hmmm...


It's an awful idea. It's a non-idea. If "idea" had an antonym, that 
would be it.

I can't fathom what's on the mind of a person (not you, at least you
foresee some potential problems) who, even after patiently explained the
issues with this mental misfire, several times, still can bring
themselves to think it's not that bad.

Let me add one more, although more than sure someone will find a remedy
for it, too.

a...b

vs.

a.. .b

and of course the beauty

a....b

I don't plan to discuss minor features on this group anymore.


Andrei
May 19 2009
next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that would be
 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.


Maybe if you weren't prone to such humorous bouts of hyperbole, you
wouldn't get your blood boiling so easily.  This is the internet, and
we're talking about programming languages.  It's not like we're
defusing a tense international arms conflict or something.
May 19 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:

 On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that woul=




d be

 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.


 Maybe if you weren't prone to such humorous bouts of hyperbole, you
 wouldn't get your blood boiling so easily. =A0This is the internet, and
 we're talking about programming languages. =A0It's not like we're
 defusing a tense international arms conflict or something.


Also, why does the puremagic mailing list software hate me so much
when it comes to threading my replies?
May 19 2009
next sibling parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jarrett Billingsley wrote:

 On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:

 On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that would be
 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.


 Maybe if you weren't prone to such humorous bouts of hyperbole, you
 wouldn't get your blood boiling so easily.  This is the internet, and
 we're talking about programming languages.  It's not like we're
 defusing a tense international arms conflict or something.


 
 Also, why does the puremagic mailing list software hate me so much
 when it comes to threading my replies?


You're probably breaching some volume of posts limit. ;)
Thunderbird works nice.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKEybQT9LetA9XoXwRAkDXAKCo9PS0+GRCCyZibMe3WcbiZo5HlgCeMp92
fUcS3bLFqSaQ/Pk8KKVNzJM=
=k/lq
-----END PGP SIGNATURE-----
May 19 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 5:38 PM, div0 <div0 users.sourceforge.net> wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 Jarrett Billingsley wrote:

 On Tue, May 19, 2009 at 4:47 PM, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:

 On Tue, May 19, 2009 at 4:43 PM, Andrei Alexandrescu

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that wo=








uld be

 it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained t=








he

 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.

 Let me add one more, although more than sure someone will find a remed=








y

 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b

 I don't plan to discuss minor features on this group anymore.


 Maybe if you weren't prone to such humorous bouts of hyperbole, you
 wouldn't get your blood boiling so easily. =A0This is the internet, and
 we're talking about programming languages. =A0It's not like we're
 defusing a tense international arms conflict or something.


 Also, why does the puremagic mailing list software hate me so much
 when it comes to threading my replies?


 You're probably breaching some volume of posts limit. ;)
 Thunderbird works nice.

 - --
 My enormous talent is exceeded only by my outrageous laziness.
 http://www.ssTk.co.uk
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

 iD8DBQFKEybQT9LetA9XoXwRAkDXAKCo9PS0+GRCCyZibMe3WcbiZo5HlgCeMp92
 fUcS3bLFqSaQ/Pk8KKVNzJM=3D
 =3Dk/lq
 -----END PGP SIGNATURE-----


I'd vastly prefer a newsreader.  Sadly I've yet to encounter a
newsreader that can store its state in a shared location, which is
important for me as I need to be able to access the newsgroups from
multiple computers.  Cough, googlegroups, cough, but whatever.

It might be the way I snip out parts of quoted posts.  Maybe it
doesn't like that.
May 19 2009
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 19 May 2009 16:48:41 -0400, Jarrett Billingsley  
<jarrett.billingsley gmail.com> wrote:


 Also, why does the puremagic mailing list software hate me so much
 when it comes to threading my replies?


FWIW, your replies also sometimes thread your replies in a new thread in  
opera (and I recall this happening with Outlook Express before I  
switched).  There must be something your client isn't transmitting  
properly to signal it's the continuation of a thread.

Probably you should examine your headers closely on replies that do get  
threaded properly vs. replies that for some reason start a new thread.

-Steve
May 19 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


In about two years I've never heard Walter say something like that (even if may
think similar things every day), he doesn't need a pedestal. 

Thank you,
bearophile
May 19 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


 
 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.


This has nothing to do with a pedestal. It's simple pragmatics. We are 
fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) 
around here, and that's counterproductive.

Some of language design and most of syntax design are subjective. We all 
have a tendency to subjectively prefer features that we created and to 
be more critical of features that others have created. It's natural. 
They call it the better-than-average bias 
(http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that tendency 
as much as the next guy, but I also like to believe I do not let that 
mask my reasoning too bad. That is, I wouldn't go at any length to 
defend a no-win case and argue against others while at the same time 
consistently ignoring any explanation given several times and in several 
forms.

Case in point: omitting the trailing parens in function calls... I got 
destroyed on that one :o).


Andrei
May 19 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.


 
 This has nothing to do with a pedestal. It's simple pragmatics. We are 
 fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) 
 around here, and that's counterproductive.
 
 Some of language design and most of syntax design are subjective. We all 
 have a tendency to subjectively prefer features that we created and to 
 be more critical of features that others have created. It's natural. 
 They call it the better-than-average bias 
 (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that tendency 
 as much as the next guy, but I also like to believe I do not let that 
 mask my reasoning too bad. That is, I wouldn't go at any length to 
 defend a no-win case and argue against others while at the same time 
 consistently ignoring any explanation given several times and in several 
 forms.
 
 Case in point: omitting the trailing parens in function calls... I got 
 destroyed on that one :o).
 
 
 Andrei


I think the other effect is we don't often have time to think about our 
suggestions for very long... Design is a process and something often 
"sounds good at the time". Consider the A{} syntax for templates... a 
whole newsgroup, a month of discussion, and it took until Walter started 
implementing it to realize the syntactic ambiguity.

Having more heads to think about a syntactic change can't be a bad thing.
May 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Fraser wrote:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.


 This has nothing to do with a pedestal. It's simple pragmatics. We are 
 fulfilling Wadler's law 
 (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and 
 that's counterproductive.

 Some of language design and most of syntax design are subjective. We 
 all have a tendency to subjectively prefer features that we created 
 and to be more critical of features that others have created. It's 
 natural. They call it the better-than-average bias 
 (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that 
 tendency as much as the next guy, but I also like to believe I do not 
 let that mask my reasoning too bad. That is, I wouldn't go at any 
 length to defend a no-win case and argue against others while at the 
 same time consistently ignoring any explanation given several times 
 and in several forms.

 Case in point: omitting the trailing parens in function calls... I got 
 destroyed on that one :o).


 Andrei


 
 I think the other effect is we don't often have time to think about our 
 suggestions for very long... Design is a process and something often 
 "sounds good at the time". Consider the A{} syntax for templates... a 
 whole newsgroup, a month of discussion, and it took until Walter started 
 implementing it to realize the syntactic ambiguity.
 
 Having more heads to think about a syntactic change can't be a bad thing.


Good point. "Think" is key :o). I'm sure it's often happened to many of 
us to share with a friend something we spent nights poring over, for 
them to come with what they're convinced is a much better idea after 
dignifying the matter with five seconds worth of thinking.


Andrei
May 19 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Robert Fraser wrote:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.


 This has nothing to do with a pedestal. It's simple pragmatics. We 
 are fulfilling Wadler's law 
 (http://www.haskell.org/haskellwiki/Wadlers_Law) around here, and 
 that's counterproductive.

 Some of language design and most of syntax design are subjective. We 
 all have a tendency to subjectively prefer features that we created 
 and to be more critical of features that others have created. It's 
 natural. They call it the better-than-average bias 
 (http://en.wikipedia.org/wiki/Lake_Wobegon_effect). I have that 
 tendency as much as the next guy, but I also like to believe I do not 
 let that mask my reasoning too bad. That is, I wouldn't go at any 
 length to defend a no-win case and argue against others while at the 
 same time consistently ignoring any explanation given several times 
 and in several forms.

 Case in point: omitting the trailing parens in function calls... I 
 got destroyed on that one :o).


 Andrei


 I think the other effect is we don't often have time to think about 
 our suggestions for very long... Design is a process and something 
 often "sounds good at the time". Consider the A{} syntax for 
 templates... a whole newsgroup, a month of discussion, and it took 
 until Walter started implementing it to realize the syntactic ambiguity.

 Having more heads to think about a syntactic change can't be a bad thing.


 
 Good point. "Think" is key :o).


And another thing is, of course, that even a simple language can become 
too hard for a normal programmer, if it becomes too elegant or assumes 
too much generalizing, memorizing, and abstract thinking from the 
programmer when he is coding.

Some of the vociferous things (well, like the trailing parens thing) may 
be related to that.

So, this NG serves a purpose in helping the language stay near most 
regular programmers' reach. Wich is a must, if we intend to take over 
the world.
May 19 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.


 
 This has nothing to do with a pedestal. It's simple pragmatics. We are 
 fulfilling Wadler's law (http://www.haskell.org/haskellwiki/Wadlers_Law) 
 around here, and that's counterproductive.


Yeah. But more important is, of course, that you are important to the 
development of D, even on your own. That means, that unless you are 
careful with the time spent on this newsgroup, it will unduely eat away 
from your time with actual development. (And even thinking, in some cases.)

For example, spending copious amounts of ink on trying to explain some 
of the most esoteric features to some who have no chance of getting it 
with any amount of explanation, is a waste of time. Let the ideas 
trickle down. At the end of the day (er, actually, the month), the guys 
sitting next to him will explain it in more suitable terms anyway.

Also, sometimes being too terse, only causes a flurry of (either 
misunderstandings, or) a barrage of questions, that you then have to 
answer, instead of answering properly the first time around.

BUT, THIS IS not important, and please, don't take the above personally. 
It was just thoughts in response to "not planning to discuss minor 
features". They're important too.

AND I'm not perfect either. Definitely not.
May 19 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


 
 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.


Walter hasn't done it in 10 years in this NG.
May 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.


 
 Walter hasn't done it in 10 years in this NG.


There's only one Walter!

Andrei
May 19 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Georg Wrede wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


 In about two years I've never heard Walter say something like that
 (even if may think similar things every day), he doesn't need a
 pedestal.


 Walter hasn't done it in 10 years in this NG.


 
 There's only one Walter!


:-)
May 19 2009
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Andrei Alexandrescu wrote:

 Let me add one more, although more than sure someone will find a remedy
 for it, too.
 
 a...b
 
 vs.
 
 a.. .b
 
 and of course the beauty
 
 a....b


Oh, and this speaks more about the .b syntax than anything else. Does 
anyone actually use this...? If it was removed, b could still be 
accessed by its fully-qualified name, so its' removal not a huge loss.
May 19 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:

 Andrei Alexandrescu wrote:

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b

 and of course the beauty

 a....b


 
 Oh, and this speaks more about the .b syntax than anything else. Does 
 anyone actually use this...? If it was removed, b could still be 
 accessed by its fully-qualified name, so its' removal not a huge loss.


"But that will make porting C code harder"

Guess who'll say that. ;-)
May 19 2009
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Ary Borenszweig wrote:

 Oh, and this speaks more about the .b syntax than anything else. Does 
 anyone actually use this...? If it was removed, b could still be 
 accessed by its fully-qualified name, so its' removal not a huge loss.


 
 "But that will make porting C code harder"
 
 Guess who'll say that. ;-)


??? C allows .x to access a global member? You learn something useless 
every day...
May 19 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:

 Ary Borenszweig wrote:

 Oh, and this speaks more about the .b syntax than anything else. Does 
 anyone actually use this...? If it was removed, b could still be 
 accessed by its fully-qualified name, so its' removal not a huge loss.


 "But that will make porting C code harder"

 Guess who'll say that. ;-)


 
 ??? C allows .x to access a global member? You learn something useless 
 every day...


Aaaaaaaaaaah... I thought they were talking about .1, .2, etc.

I forgot about .foo
May 19 2009
prev sibling next sibling parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Andrei Alexandrescu wrote:

 Robert Fraser wrote:

 Frank Benoit wrote:

 Alexander Pánek schrieb:

 Andrei Alexandrescu wrote:

 bearophile wrote:

 Andrei Alexandrescu:

 Thank you for bringing a "real" example that gives something to 
 work on.


 Awful!<


 Well, one of your cases was wrong. Using the +1 at the end one of
 those cases become:
 case 'A' .. 'Z'+1, 'a' .. 'z'+1:
 Instead of what you have written:
 case 'A' .. 'Z'+1: case 'a' .. 'z'+1:

 I agree that that syntax with +1 isn't very nice looking. But the
 advantage of +1 is that it introduces (almost) no new syntax, it's
 not easy to miss, its meaning is easy to understand. AND you don't
 have to remember that in a case the .. is inclusive while in foreach
 is exclusive on the right, keeping the standard way in D to denote
 ranges.


 You don't understand. My point is not that people will dislike 'Z'+1.
 They will FORGET TO WRITE THE BLESSED +1. They'll write:

 case 'A' .. 'Z':


 You know, Ruby solves this by introducing a “seperate” range syntax for
 exclusive ranges: “...”. An inclusive range is written the same as an
 exclusive range in D: “..”.




 I see no reason not to include such a seperate syntax in D. “..” being
 exclusive and “...” being inclusive, not the other way round as in Ruby
 — see “Programmer’s Paradox”  
 http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .

 Kind regards, Alex


 Yes, this is useful for all use cases of ranges.
 I like '...'.


 Indeed it's not a bad idea... But it might be easily mistyped, lead to 
 strange off-by-one errors and be very difficult to find while 
 debugging them. Hmmm...


 
 It's an awful idea. It's a non-idea. If "idea" had an antonym, that 
 would be it.
 
 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.


I don’t see a reason not to restrict other features to introduce a new 
one. I never used .foo to access the global scope or .1 for floating 
point literals. But what I do use very often is array[n..m + 1], which 
would ease things for quite a lot of things going on when working with 
arrays. Of course it’s just syntactic sugar, but so is the whole slicing 
feature. It could easily be done in the standard library.

So I’m not demanding anything, I’m just providing my very own thoughts 
on this topic. If there are too many obstacles then it’s probably not 
worth it. The thing is, I don’t know half as much as most of the guys 
here do, so I don’t see those obstacles at first glance. Please bear 
with me. :)


 Let me add one more, although more than sure someone will find a remedy
 for it, too.
 
 a...b


inclusive range from a to b


 vs.
 
 a.. .b


exclusive range from a to .b

Personally, I see “...” as an atomic operator, like “!=” or “==”. I 
wouldn’t ever recognize “.. .” as “...” or “! =” as “!=”.
Additionally, 
I add a space before and after every operator, so there’s no ambiguity 
in any way, plus it’s nicely recognizable what the hell is going on. If 
it was for me, I’d even go as far as to make this a requirement in the 
specification. But that would upset downs.

Actually, what about “…” as inclusive range operator? :P I’d love that.



 and of course the beauty
 
 a....b


Inclusive range from “a” to “.b”? Pretty clear in this *particular*
case. ;)



 I don't plan to discuss minor features on this group anymore.


But.. bike shed discussions are fun! Seriously, though — I learn a lot 
thanks to people “nitpicking” other people’s ideas, showing corner 
cases, obstacles and so on. So please, don’t stop discussing minor 
features. :)
May 20 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.


Your post is emotional rather than rational.


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b


a..b vs a.b - no one complains

It also gracefully solves an issue with uniform distribution

uniform(0..int.max)  - exclusive
uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)

also in switch:

switch(a)
{
case 0..10: // exclusive
case 10...100: // inclusive
}


 I don't plan to discuss minor features on this group anymore.


It is as minor as "case a: .. case b:", i.e. not minor at all.
I'd say that there is no such thing as minor feature, every feature is
important.


 Andrei
May 20 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 

 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.


 
 Your post is emotional rather than rational.


Agreed. In my defense, let me mention that I've been rational in my 
previous 50 posts on the topic :o).


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b


 
 a..b vs a.b - no one complains


You see, you didn't understand my point. My point was that the 
introduction of a space changes semantics. We should avoid that.


 It also gracefully solves an issue with uniform distribution
 
 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)


Yeah, and this does something else:

uniform(0....int.max)

and if you use an alias we also have:

uniform(0.....A.max)

It's interesting how there is a continuum of number of "." that still 
lead to compilable code that does different things every time. Perfect 
material for "Why D is a horrible language" articles.


Andrei
May 20 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.


 Your post is emotional rather than rational.


 
 Agreed. In my defense, let me mention that I've been rational in my 
 previous 50 posts on the topic :o).
 

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b


 a..b vs a.b - no one complains


 
 You see, you didn't understand my point. My point was that the 
 introduction of a space changes semantics. We should avoid that.
 

 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)


 
 Yeah, and this does something else:
 
 uniform(0....int.max)
 
 and if you use an alias we also have:
 
 uniform(0.....A.max)
 
 It's interesting how there is a continuum of number of "." that still 
 lead to compilable code that does different things every time. Perfect 
 material for "Why D is a horrible language" articles.


This is easily solved by making the lexer not allow the "...." token, or 
   "....." token, etc. (maximum 3 dots.) This way you are forced to 
insert a space there to make your intention clear, and you can never 
have bugs like that.

Perfect material for "Why D is a beautiful language" articles.
May 20 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:

 This is easily solved by making the lexer not allow the "...." token, or 
   "....." token, etc. (maximum 3 dots.) This way you are forced to 
 insert a space there to make your intention clear, and you can never 
 have bugs like that.


I agree that things could be fixed. This is, however, a hack because a 
lexer is not supposed to operate that way. Lexers are "maximum munch".

So we're looking at a number of problems here. One is that we'd need to 
change the language in several places to accommodate an ill-conceived 
feature. Another is that I can't seem to get some very simple points 
across such as the difference between a token and a non-terminal, in 
spite of having tried repeatedly and in various forms. Another is that I 
am becoming suffocated with self-righteousness and therefore am losing 
goodwill in this thread at an exponentially-increasing rate. Finally, it 
looks like such discussions necessitate more than a full-time job.


Andrei
May 20 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Andrei Alexandrescu wrote:

...

 
 So we're looking at a number of problems here. One is that we'd need to 
 change the language in several places to accommodate an ill-conceived 
 feature. Another is that I can't seem to get some very simple points 
 across such as the difference between a token and a non-terminal, in 
 spite of having tried repeatedly and in various forms. Another is that I 
 am becoming suffocated with self-righteousness and therefore am losing 
 goodwill in this thread at an exponentially-increasing rate. Finally, it 
 looks like such discussions necessitate more than a full-time job.
 
 
 Andrei


You could ask Walter for advice on most of these matters ;)
May 20 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that
 =A0would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained th=






e

 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.


 Your post is emotional rather than rational.


 Agreed. In my defense, let me mention that I've been rational in my previ=


ous

 50 posts on the topic :o).


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b


 a..b vs a.b - no one complains


 You see, you didn't understand my point. My point was that the introducti=


on

 of a space changes semantics. We should avoid that.


 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max) =A0- exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)


 Yeah, and this does something else:

 uniform(0....int.max)

 and if you use an alias we also have:

 uniform(0.....A.max)

 It's interesting how there is a continuum of number of "." that still lea=


d

 to compilable code that does different things every time. Perfect materia=


l

 for "Why D is a horrible language" articles.


Isn't 0...a already a horrendously awful non-idea and mental misfire
by these arguments?

--bb
May 20 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Wed, May 20, 2009 at 7:28 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that
  would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.


 Your post is emotional rather than rational.


 Agreed. In my defense, let me mention that I've been rational in my previous
 50 posts on the topic :o).


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b


 a..b vs a.b - no one complains


 You see, you didn't understand my point. My point was that the introduction
 of a space changes semantics. We should avoid that.


 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)


 Yeah, and this does something else:

 uniform(0....int.max)

 and if you use an alias we also have:

 uniform(0.....A.max)

 It's interesting how there is a continuum of number of "." that still lead
 to compilable code that does different things every time. Perfect material
 for "Why D is a horrible language" articles.


 
 Isn't 0...a already a horrendously awful non-idea and mental misfire
 by these arguments?
 
 --bb


The problems increase exponentially with the number of dots.

Andrei
May 20 2009
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.


 Your post is emotional rather than rational.


 
 Agreed. In my defense, let me mention that I've been rational in my 
 previous 50 posts on the topic :o).
 

 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b


 a..b vs a.b - no one complains


 
 You see, you didn't understand my point. My point was that the 
 introduction of a space changes semantics. We should avoid that.
 


Like,

a- --b

vs.

a-- -b

?


 It also gracefully solves an issue with uniform distribution

 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)


 
 Yeah, and this does something else:
 
 uniform(0....int.max)
 
 and if you use an alias we also have:
 
 uniform(0.....A.max)
 
 It's interesting how there is a continuum of number of "." that still 
 lead to compilable code that does different things every time. Perfect 
 material for "Why D is a horrible language" articles.
 
 
 Andrei
May 20 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
KennyTM~ wrote:

 Andrei Alexandrescu wrote:

 Denis Koroskin wrote:

 On Wed, 20 May 2009 00:43:56 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:


 It's an awful idea. It's a non-idea. If "idea" had an antonym, that  
 would be it.

 I can't fathom what's on the mind of a person (not you, at least you
 foresee some potential problems) who, even after patiently explained 
 the
 issues with this mental misfire, several times, still can bring
 themselves to think it's not that bad.


 Your post is emotional rather than rational.


 Agreed. In my defense, let me mention that I've been rational in my 
 previous 50 posts on the topic :o).


 Let me add one more, although more than sure someone will find a remedy
 for it, too.

 a...b

 vs.

 a.. .b


 a..b vs a.b - no one complains


 You see, you didn't understand my point. My point was that the 
 introduction of a space changes semantics. We should avoid that.


 
 Like,
 
 a- --b
 
 vs.
 
 a-- -b
 
 ?


Yes, like that. I didn't say there aren't any right now. I said we 
should avoid that.


Andrei
May 20 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Denis Koroskin:

 It also gracefully solves an issue with uniform distribution
 uniform(0..int.max)  - exclusive
 uniform(0...int.max) - inclusive (can't be replaced with 0..int.max+1)




uniform(0 .. int.max)  - exclusive


Bye,
bearophile
May 20 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
bearophile wrote:

 
 void classify(char c) {
     write("You passed ");
     switch (c) {

           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }


(A bunch of other versions omitted.)...


  void classify(char c) {
      write("You passed ");
      switch (c) {

            writeln("a hash sign.");
            break;
         case '0' .. case '9':
            writeln("a digit.");
            break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
            break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
            break;
         default:
            writeln("quite a character!");
            break;
      }
  }

This is usable, easy to read -- and the programmer has no problem to 
remember that .. works differently in case statements than in ranges.

There are other places in D that place an undue burden on the 
programmer, but this is not IMHO one of them.

--------------------

My pet peeve with case is that, since we don't seem to be getting rid of 
break (and use some word for fall-through instead, "which would save a 
good deal of ink"), we should at least try to make break more 
conspicuous. I can name a hundred times I've forgotten a break from 
somewhere. So the canonical indentation should be like this:


  void classify(char c) {
      write("You passed ");
      switch (c) {

            writeln("a hash sign.");
         break;
         case '0' .. case '9':
            writeln("a digit.");
         break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
         break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
         break;
         default:
            writeln("quite a character!");
         break;
      }
  }

(It'd look better when the cases have more lines, but still.) Currently 
in D, break is at least as important as case, therefore it deserves a 
conspicuous place, hence my suggestion.
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:

 bearophile wrote:

 void classify(char c) {
     write("You passed ");
     switch (c) {

           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }


 (A bunch of other versions omitted.)...
 
 
  void classify(char c) {
      write("You passed ");
      switch (c) {

            writeln("a hash sign.");
            break;
         case '0' .. case '9':
            writeln("a digit.");
            break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
            break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
            break;
         default:
            writeln("quite a character!");
            break;
      }
  }
 
 This is usable, easy to read -- and the programmer has no problem to 
 remember that .. works differently in case statements than in ranges.


I'd like to keep the (non-required) colon after the first expression in 
a ".." pair of case labels, that is:

case '0': .. case '9':

as opposed to

case '0' .. case '9':

That way it is abundantly clear that the notation has nothing in common 
with expression1 .. expression2. The error message if someone forgot the 
':' can easily be made clear.


Andrei
May 18 2009
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-05-18 22:39:23 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 I'd like to keep the (non-required) colon after the first expression in 
 a ".." pair of case labels, that is:
 
 case '0': .. case '9':
 
 as opposed to
 
 case '0' .. case '9':
 
 That way it is abundantly clear that the notation has nothing in common 
 with expression1 .. expression2. The error message if someone forgot 
 the ':' can easily be made clear.


You could have '::' denote an inclusive range. :-)

	case '0'..'9': // '9' excluded
	case '0'::'9': // '9' included

Seriously, I don't care much what the syntax is as long as it's 
different from the one used for exclusive range. Both:

	case '0': .. case '9':

looks acceptable to me. Although I agree with others about the 
inconsistency of using ".." for an inclusive range, having it finish 
with "case '9':" seems to indicate clearly the intent to include the 
last element.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 18 2009
prev sibling next sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Georg Wrede wrote:

 bearophile wrote:

 void classify(char c) {
     write("You passed ");
     switch (c) {

           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }


 (A bunch of other versions omitted.)...


  void classify(char c) {
      write("You passed ");
      switch (c) {

            writeln("a hash sign.");
            break;
         case '0' .. case '9':
            writeln("a digit.");
            break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
            break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
            break;
         default:
            writeln("quite a character!");
            break;
      }
  }

 This is usable, easy to read -- and the programmer has no problem to 
 remember that .. works differently in case statements than in ranges.


 
 I'd like to keep the (non-required) colon after the first expression in 
 a ".." pair of case labels, that is:
 
 case '0': .. case '9':
 
 as opposed to
 
 case '0' .. case '9':
 
 That way it is abundantly clear that the notation has nothing in common 
 with expression1 .. expression2. The error message if someone forgot the 
 ':' can easily be made clear.


So concatenating ranges would be

     case '0': .. case '9': case 'a': .. case 'z':
         do something

which then could be written, depending on programmer preferences

     case '0':
     .. case '9':
     case 'a':
     .. case 'z':
         do something

or

     case '0': .. case '9':
     case 'a': .. case 'z':
         do something

While I'd prefer to omit the colon, I can live with it.
May 18 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 19 May 2009 06:39:23 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


 Georg Wrede wrote:

 bearophile wrote:

 void classify(char c) {
     write("You passed ");
     switch (c) {

           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }


 (A bunch of other versions omitted.)...
    void classify(char c) {
      write("You passed ");
      switch (c) {

            writeln("a hash sign.");
            break;
         case '0' .. case '9':
            writeln("a digit.");
            break;
         case 'A' .. case 'Z':
         case 'a' .. case 'z':
            writeln("an ASCII character.");
            break;
         case '.', ',', ':', ';', '!', '?':
            writeln("a punctuation mark.");
            break;
         default:
            writeln("quite a character!");
            break;
      }
  }
  This is usable, easy to read -- and the programmer has no problem to  
 remember that .. works differently in case statements than in ranges.


 I'd like to keep the (non-required) colon after the first expression in  
 a ".." pair of case labels, that is:

 case '0': .. case '9':

 as opposed to

 case '0' .. case '9':

 That way it is abundantly clear that the notation has nothing in common  
 with expression1 .. expression2. The error message if someone forgot the  
 ':' can easily be made clear.


 Andrei


Will it be possible to write like this?

void classify(char c) {
   write("You passed ");
   switch (c) {
      case '0':
      ..
      case '9':
         writeln("a digit.");
         break;
      case 'A':
      ..
      case 'Z':
         writeln("upper case ASCII character.");
         break;
      case 'a':
      ..
      case 'z':
         writeln("lower case ASCII character.");
         break;
      case '.', ',', ':', ';', '!', '?':
         writeln("a punctuation mark.");
         break;
      default:
         writeln("quite a character!");
         break;
   }
}

Looks cool!
May 19 2009
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Georg Wrede wrote:

 This is usable, easy to read -- and the programmer has no problem to
 remember that .. works differently in case statements than in ranges.


You're making two assumptions here:
1. That inclusive ranges are preferable inside 'case' statements.
2. That non-inclusive ranges are preferable outside 'case' statements.

I don't buy it.  The issue of inclusive versus non-inclusive ranges is
*exactly the same* in and outside 'case' statements.

// Non-inclusive:
foreach (c; start .. middle) doA(c);
foreach (c; middle .. end) doB(c);
foreach (c; start .. end) {
  switch (c) {
    case start .. middle:
      doA(c);
      break;
    case middle .. end:
      doA(c);
      break;
  }
}

// Inclusive:
foreach (c; 'a' ... 'z') doSomething(c);
switch (c) {
  case 'a' ... 'z':
    doSomething(c);
    break;
}
foreach (c; 0 ... int.max) doSomething(c);
switch (c) {
  case 0 ... int.max:
    doSomething(c);
    break;
}


Since I don't accept your assumptions, I see no point in arguing whether
or not those assumptions would justify overloading the '..' operator to
have one meaning in 'case' statements and another meaning elsewhere.


-- 
Rainer Deyke - rainerd eldwood.com
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:

 Georg Wrede wrote:

 This is usable, easy to read -- and the programmer has no problem to
 remember that .. works differently in case statements than in ranges.


 
 You're making two assumptions here:
 1. That inclusive ranges are preferable inside 'case' statements.


Yes. The point of case a: .. case b: is to save you from writing case a: 
case a+1: and so on up to case b:. There is no exclusion. You write now 
the cases you want to handle.


 2. That non-inclusive ranges are preferable outside 'case' statements.


Of course. One word: STL.


 I don't buy it.  The issue of inclusive versus non-inclusive ranges is
 *exactly the same* in and outside 'case' statements.


No.


Andrei
May 18 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:

 Rainer Deyke wrote:

 You're making two assumptions here:
 1. That inclusive ranges are preferable inside 'case' statements.


 
 Yes. The point of case a: .. case b: is to save you from writing case a:
 case a+1: and so on up to case b:. There is no exclusion. You write now
 the cases you want to handle.
 

 2. That non-inclusive ranges are preferable outside 'case' statements.


 
 Of course. One word: STL.


I can think of two concrete advantages of half-open/non-inclusive ranges:
  1. When using zero-based indexing, '0 .. length' expresses all
elements in a sequence.
  2. A range can be 'split' on any point 'x' into subranges '0 .. x' and
'x .. length'.
Both of these advantages also apply to 'case' statements:

const int
  first_nullary_instruction = 5,
  first_unary_instruction = 5,
  first_binary_instruction = 10,
  num_instructions = 15;

switch (c) {
  case first_nullary_instruction .. first_unary_instruction:
    executeNullaryInstruction();
    break;
  case first_unary_instruction .. first_binary_instruction:
    executeUnaryInstruction();
    break;
  case first_binary_instruction .. num_instructions:
    executeUnaryInstruction();
    break;
  default:
    illegalInstruction();
    break;
}

I can think of two concrete advantages of inclusive ranges:
  1. The past-the-end element may not be known.
  2. The past-the-end element may not be representable.
Both of these advantages also outside 'case' statements:

foreach (i; 0 ... int.max) doSomethingWith(i);


-- 
Rainer Deyke - rainerd eldwood.com
May 18 2009
prev sibling parent reply Mike James <foo bar.com> writes:
Georg Wrede Wrote:


 bearophile wrote:

 
 void classify(char c) {
     write("You passed ");
     switch (c) {

           writeln("a hash sign.");
           break;
        case '0' ..> '9':
           writeln("a digit.");
           break;
        case 'A' ..> 'Z', 'a' ..> 'z':
           writeln("an ASCII character.");
           break;
        case '.', ',', ':', ';', '!', '?':
           writeln("a punctuation mark.");
           break;
        default:
           writeln("quite a character!");
           break;
     }
 }


 (A bunch of other versions omitted.)...
 
 
   void classify(char c) {
       write("You passed ");
       switch (c) {

             writeln("a hash sign.");
             break;
          case '0' .. case '9':
             writeln("a digit.");
             break;
          case 'A' .. case 'Z':
          case 'a' .. case 'z':
             writeln("an ASCII character.");
             break;
          case '.', ',', ':', ';', '!', '?':
             writeln("a punctuation mark.");
             break;
          default:
             writeln("quite a character!");
             break;
       }
   }
 
 This is usable, easy to read -- and the programmer has no problem to 
 remember that .. works differently in case statements than in ranges.
 
 There are other places in D that place an undue burden on the 
 programmer, but this is not IMHO one of them.
 
 --------------------
 
 My pet peeve with case is that, since we don't seem to be getting rid of 
 break (and use some word for fall-through instead, "which would save a 
 good deal of ink"), we should at least try to make break more 
 conspicuous. I can name a hundred times I've forgotten a break from 
 somewhere. So the canonical indentation should be like this:
 
 
   void classify(char c) {
       write("You passed ");
       switch (c) {

             writeln("a hash sign.");
          break;
          case '0' .. case '9':
             writeln("a digit.");
          break;
          case 'A' .. case 'Z':
          case 'a' .. case 'z':
             writeln("an ASCII character.");
          break;
          case '.', ',', ':', ';', '!', '?':
             writeln("a punctuation mark.");
          break;
          default:
             writeln("quite a character!");
          break;
       }
   }
 
 (It'd look better when the cases have more lines, but still.) Currently 
 in D, break is at least as important as case, therefore it deserves a 
 conspicuous place, hence my suggestion.



Full Circle...

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81519
May 19 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Mike James wrote:

 Full Circle...
 


If you're trying to emphasize the significance of this proposal, then good.

But if you're trying to say that one should post more original posts, 
then bad.
May 19 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:
 

 It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.


 
 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".


But it's not "blarf". It's "case". I am floored that nobody sees the 
elegance of that syntax.

Andrei
May 18 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:


 It's all a matter of perspective. I see both as begin .. end. That may =






be

 the same reason why I think addition when I see foo(bar()) + baz(37). T=






he

 extra cruft is more or less ignored when figuring out the basics of wha=






t is

 going on.


 Agreed. =A0If you tell someone =A0 a .. b =A0means a non-inclusive range
 from a to b, then ask them to guess what =A0 =A0blarf a .. blarf b =A0me=




ans,

 I would be very surprised if many guessed "inclusive range from blarf
 a =A0to blarf b".


 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.


So your argument is that "case" inherently deserves a special case?

I don't think it's a terrible syntax, but I wouldn't go as far as to
call it elegant.  I'm with bear that it would be better if we could
come up with some syntax that means "inclusive range" everywhere.
Rather than introducing special cases.  Special cases are generally a
sign that something has gone wrong in a language design.

--bb
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, May 18, 2009 at 4:02 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:


 It's all a matter of perspective. I see both as begin .. end. That may be
 the same reason why I think addition when I see foo(bar()) + baz(37). The
 extra cruft is more or less ignored when figuring out the basics of what is
 going on.


 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".


 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.


 
 So your argument is that "case" inherently deserves a special case?


It has been a keyword with a specific meaning for many years. That's 
bound to mean something.


 I don't think it's a terrible syntax, but I wouldn't go as far as to
 call it elegant.  I'm with bear that it would be better if we could
 come up with some syntax that means "inclusive range" everywhere.
 Rather than introducing special cases.  Special cases are generally a
 sign that something has gone wrong in a language design.


I completely disagree that that's a special case. ".." is punctuation. 
You can't pretend punctuation has the same meaning everywhere in a 
programming language.

Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.


I'm a bit confused. Are you saying that one must expect that the meaning of
punctuation in a programming language depends on the context the
punctuation is found in?

If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a
.. b:" can mean inclusive range, no?


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:
 

 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.


 
 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?


How many meanings does '[' have in your favorite programming language?


Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:
 

 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.


 
 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?


 
 How many meanings does '[' have in your favorite programming language?


One.

But how is your question an answer to my question?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:
 

 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.


 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?


 How many meanings does '[' have in your favorite programming language?


 
 One.


No.

Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:
 

 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.


 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?


 How many meanings does '[' have in your favorite programming language?


 
 One.


 
 No.


But you never asked for the name of my favourite language?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:
 

 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.


 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?


 How many meanings does '[' have in your favorite programming language?


 One.


 No.


 
 But you never asked for the name of my favourite language?
 


Yah, I realized my flawed supposition after sending :o). So, what is it?

Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:20:11 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 But you never asked for the name of my favourite language?




 

 Yah, I realized my flawed supposition after sending :o). So, what is it?


Actually I have two - Forth and Euphoria, but D comes a close second.

Anyways ... back to the actually question that I asked and you haven't got
around to answering yet -- (you're not doing politian training are you :-))

On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation. 
 You can't pretend punctuation has the same meaning everywhere in a 
 programming language.


I'm a bit confused. Are you saying that one must expect that the meaning of
punctuation in a programming language depends on the context the
punctuation is found in?

If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a
.. b:" can mean inclusive range, no?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?
 
 If so, then ".." in "[a .. b]" can mean exclusive range and ".." in "case a
 .. b:" can mean inclusive range, no?


No, you don't understand. But I sworn that I'll explain it for the last 
time in another post, so I'm out of times I can explain it.

Let me make a separate point. With "...", people just defined the space 
operator. What's the space operator? Changes the meaning of 0...10 in 
two distinct ways:

0...10 is an all-inclusive integer range from 0 to 10
0. ..10 is a right-open floating-point range from 0 to 10
0.. .10 is a right-open floating-point range from 0 to 0.1

Not to mention:

0.....10 is an all-inclusive floating-point range from 0 to .1 (if I 
counted my dots right).

I have no doubt somebody will find this all intuitive and pleasing on 
the eye, and will suggest a couple of additional constructs and keywords 
to improve things.


Andrei
May 18 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gutd12$16h9$1 digitalmars.com...

 Let me make a separate point. With "...", people just defined the space 
 operator. What's the space operator? Changes the meaning of 0...10 in two 
 distinct ways:

 0...10 is an all-inclusive integer range from 0 to 10
 0. ..10 is a right-open floating-point range from 0 to 10
 0.. .10 is a right-open floating-point range from 0 to 0.1


So '1.' and '.1'  are legal numbers in D? I would have assumed that any 
numerical literal with a decimal point would require at least one digit on 
both sides of the decimal point. Not sure I see a good reason for this not 
to be required.
May 19 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gutd12$16h9$1 digitalmars.com...

 Let me make a separate point. With "...", people just defined the space 
 operator. What's the space operator? Changes the meaning of 0...10 in two 
 distinct ways:

 0...10 is an all-inclusive integer range from 0 to 10
 0. ..10 is a right-open floating-point range from 0 to 10
 0.. .10 is a right-open floating-point range from 0 to 0.1


 
 So '1.' and '.1'  are legal numbers in D? I would have assumed that any 
 numerical literal with a decimal point would require at least one digit on 
 both sides of the decimal point. Not sure I see a good reason for this not 
 to be required. 


Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even 
if we don't consider "the new space operator" implications!!!!!! It 
really makes it hard to spot the odd decimal value when you're not 
expecting it there.

That's mainly an American invention. In Europe, in most countries, you 
couldn't ever write .1 without everybody shouting typo!

Had D been invented in Europe, .1 would never have crossed anybodys 
mind. After several decades, I'm still uncomfortable when anybody writes 
.1, be it in programming or on street billboards.


Then we could go on (not that Andrei ever meant it, so I'm not serious 
here), and write

1.0..2.0   an all-inclusive floating range from 1.0 to 2.0
1.0 ..2.0   a right-inclusive floating range from 1.0 to 2.0
1.0.. 2.0   a left-inclusive floating range from 1.0 to 2.0
1.0 .. 2.0   a non-inclusive floating range from 1.0 to 2.0

1..2   an all-inclusive integer range from 1 to 2
1 ..2   a right-inclusive integer range from 1 to 2
1.. 2   a left-inclusive integer range from 1 to 2
1 .. 2   a non-iclusive integer range from 1 to 2

(And we didn't even need the triple-dot operator!)

But this would break existing code, make white-space significant, choke 
Andrei, pop Walter's ulcer, and generally be reminiscent of interpreted 
languages (read: embarrassing).

(Not that whitespace isn't already significant in a way, otherwise we 
could write 1 . 2 and it would be the same thing as 1.2.)


Actually, I'm not sure there would be ambuguity with the American 
decimals, either:

1....2   an all-inclusive range from 1. to .2
1. ...2   a right-inclusive range from 1. to .2
1... .2   a left-inclusive range from 1. to .2
1. .. .2   a non-inclusive range from 1. to .2
1...2   Error: improperly mixing integers and floating point.

Note, I'm personally against having decimals in ranges in the first place.
May 19 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 19, 2009 at 8:37 AM, Georg Wrede <georg.wrede iki.fi> wrote:


 So '1.' and '.1' =A0are legal numbers in D? I would have assumed that an=




y

 numerical literal with a decimal point would require at least one digit =




on

 both sides of the decimal point. Not sure I see a good reason for this n=




ot

 to be required.


 Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even i=


f

 we don't consider "the new space operator" implications!!!!!! It really
 makes it hard to spot the odd decimal value when you're not expecting it
 there.

 That's mainly an American invention. In Europe, in most countries, you
 couldn't ever write .1 without everybody shouting typo!

 Had D been invented in Europe, .1 would never have crossed anybodys mind.
 After several decades, I'm still uncomfortable when anybody writes .1, be=


 it

 in programming or on street billboards.


For what it's worth, I'm American and have neither seen the 'one-sided
floating-point number' used in public nor am I comfortable with it
being in a programming language.  It just doesn't look right.
May 19 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Jarrett Billingsley wrote:

 On Tue, May 19, 2009 at 8:37 AM, Georg Wrede <georg.wrede iki.fi> wrote:
 

 So '1.' and '.1'  are legal numbers in D? I would have assumed that any
 numerical literal with a decimal point would require at least one digit on
 both sides of the decimal point. Not sure I see a good reason for this not
 to be required.


 Agreed. Saving ink in 1. versus 1.0 and .1 versus 0.1 is stupid -- even if
 we don't consider "the new space operator" implications!!!!!! It really
 makes it hard to spot the odd decimal value when you're not expecting it
 there.

 That's mainly an American invention. In Europe, in most countries, you
 couldn't ever write .1 without everybody shouting typo!

 Had D been invented in Europe, .1 would never have crossed anybodys mind.
 After several decades, I'm still uncomfortable when anybody writes .1, be it
 in programming or on street billboards.


 
 For what it's worth, I'm American and have neither seen the 'one-sided
 floating-point number' used in public nor am I comfortable with it
 being in a programming language.  It just doesn't look right.


Yeah. If it was up to me, it'd be forbidden.
May 19 2009
parent reply =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Georg Wrede wrote:

 Jarrett Billingsley wrote:

 On Tue, May 19, 2009 at 8:37 AM, Georg Wrede <georg.wrede iki.fi> wrote:

 After several decades, I'm still uncomfortable when anybody writes 
 .1, be it
 in programming or on street billboards.


 For what it's worth, I'm American and have neither seen the 'one-sided
 floating-point number' used in public nor am I comfortable with it
 being in a programming language.  It just doesn't look right.


 
 Yeah. If it was up to me, it'd be forbidden.
 


Same here.
May 19 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Alexander Pánek:

 Same here.


I too don't like .56, I add a zero when I see a literal like that in the code.
But what about Walter? :-)

Bye,
bearophile
May 19 2009
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bearophile wrote:

 Alexander Pánek:

 Same here.


 
 I too don't like .56, I add a zero when I see a literal like that in the code.
But what about Walter? :-)
 
 Bye,
 bearophile


I always use it, but I won't be bothered if it was outlawed.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKEvG/T9LetA9XoXwRAkIaAKCdqOLBL9X+KwRm/vAmtoxVR4KXCQCeOaQt
Tsgo4JIuNIfP9UgiTaMLLtM=
=eo39
-----END PGP SIGNATURE-----
May 19 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Tue, May 19, 2009 at 10:51 AM, div0 <div0 users.sourceforge.net> wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1

 bearophile wrote:

 Alexander P=E1nek:

 Same here.


 I too don't like .56, I add a zero when I see a literal like that in the=




 code. But what about Walter? :-)

 Bye,
 bearophile


 I always use it, but I won't be bothered if it was outlawed.


I use it too.  Looks fine to me.  I also use  the 3.f  form on
occasion to get an integral float.

--bb
May 19 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Georg Wrede" <georg.wrede iki.fi> wrote in message 
news:guu95i$2p6c$1 digitalmars.com...

 That's mainly an American invention. In Europe, in most countries, you 
 couldn't ever write .1 without everybody shouting typo!


*shrug*, I've lived in the US all my life and it's never occurred to me to 
consider .1 anything but a typo (or at least laziness).



 Then we could go on (not that Andrei ever meant it, so I'm not serious 
 here), and write

 1.0..2.0   an all-inclusive floating range from 1.0 to 2.0
 1.0 ..2.0   a right-inclusive floating range from 1.0 to 2.0
 1.0.. 2.0   a left-inclusive floating range from 1.0 to 2.0
 1.0 .. 2.0   a non-inclusive floating range from 1.0 to 2.0

 1..2   an all-inclusive integer range from 1 to 2
 1 ..2   a right-inclusive integer range from 1 to 2
 1.. 2   a left-inclusive integer range from 1 to 2
 1 .. 2   a non-iclusive integer range from 1 to 2

 (And we didn't even need the triple-dot operator!)

 But this would break existing code, make white-space significant, choke 
 Andrei, pop Walter's ulcer, and generally be reminiscent of interpreted 
 languages (read: embarrassing).


Hee hee hee :)


 (Not that whitespace isn't already significant in a way, otherwise we 
 could write 1 . 2 and it would be the same thing as 1.2.)


Or "int foo" vs "intfoo".
May 19 2009
prev sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 9:17 PM, Derek Parnell <derek psych.ward> wrote:

 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation.
 You can't pretend punctuation has the same meaning everywhere in a
 programming language.


 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?


 How many meanings does '[' have in your favorite programming language?


 One.


 No.


 But you never asked for the name of my favourite language?


Does it have string or character literals?  Then there's probably at
least two meanings.  ;-P

--bb
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 21:30:41 -0700, Bill Baxter wrote:


 On Mon, May 18, 2009 at 9:17 PM, Derek Parnell <derek psych.ward> wrote:

 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation.
 You can't pretend punctuation has the same meaning everywhere in a
 programming language.


 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?


 How many meanings does '[' have in your favorite programming language?


 One.


 No.


 But you never asked for the name of my favourite language?


 
 Does it have string or character literals?  Then there's probably at
 least two meanings.  ;-P


Huh? "two meanings" of '['   ... is that what you are saying?

Ok, the language has both string literals and character literals, so how
does that imply that '[' has two meanings?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 19 2009
parent reply Max Samukha <outer space.com> writes:
On Tue, 19 May 2009 18:23:25 +1000, Derek Parnell <derek psych.ward>
wrote:


On Mon, 18 May 2009 21:30:41 -0700, Bill Baxter wrote:


 On Mon, May 18, 2009 at 9:17 PM, Derek Parnell <derek psych.ward> wrote:

 On Mon, 18 May 2009 23:02:37 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 21:47:01 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:31:23 -0500, Andrei Alexandrescu wrote:


 I completely disagree that that's a special case. ".." is punctuation.
 You can't pretend punctuation has the same meaning everywhere in a
 programming language.


 I'm a bit confused. Are you saying that one must expect that the meaning of
 punctuation in a programming language depends on the context the
 punctuation is found in?


 How many meanings does '[' have in your favorite programming language?


 One.


 No.


 But you never asked for the name of my favourite language?


 
 Does it have string or character literals?  Then there's probably at
 least two meanings.  ;-P


Huh? "two meanings" of '['   ... is that what you are saying?

Ok, the language has both string literals and character literals, so how
does that imply that '[' has two meanings?


In D, [ has at least four meanings:

auto a = [1, 2, 3]; - array initializer
a[1] - indexing operator
a[c..d] - slicing operator 
int[10] - static array declarator

C++ has [] for lambdas (no! C++ should be banned by the international
law, if there is any)
May 19 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Max Samukha wrote:

 ...
 
 In D, [ has at least four meanings:
 
 auto a = [1, 2, 3]; - array initializer
 a[1] - indexing operator
 a[c..d] - slicing operator 
 int[10] - static array declarator
 
 C++ has [] for lambdas (no! C++ should be banned by the international
 law, if there is any)


Actually, it's more like two.

a[1]
int[]
int[10]
a[c..d]

These are all subscript notation.

[1, 2, 3]
[a:b, c:d]

These are array literal notation.

From a strict, semantics nazi point of view, that's really six meanings.
But that's like arguing there's a meaningful difference between a.b and
A.b where a is a value and A is a type.

It's worth noting that I still sometimes forget that [...] is for array
literals, but I never ever forget its use for subscripting.

  -- Daniel
May 19 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:

 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.


 So your argument is that "case" inherently deserves a special case?


Thinking about it more, I guess you must actually be seeing it as a
rule of   " '..' always does the most useful thing", and the most
useful thing for switches is inclusive.  I see that as a local minimum
in the design space that would be exceeded by having a good syntax to
express inclusive ranges when you want them.

--bb
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",


Such attitude/purposes have created the monkey mess named Perl :-]

Bye,
bearophile
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:


 Bill Baxter:

 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",


 
 Such attitude/purposes have created the monkey mess named Perl :-]


I submit the D words 'static', 'auto' and 'scope' as examples of this too.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:
 

 Bill Baxter:

 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",


 Such attitude/purposes have created the monkey mess named Perl :-]


 
 I submit the D words 'static', 'auto' and 'scope' as examples of this too.


When was the last time you had trouble with "static"? Can you show a 
snippet of code that's confusing because of it?

Andrei
May 18 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 21:58:19 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 On Mon, 18 May 2009 19:53:51 -0400, bearophile wrote:
 

 Bill Baxter:

 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing",


 Such attitude/purposes have created the monkey mess named Perl :-]


 
 I submit the D words 'static', 'auto' and 'scope' as examples of this too.


 
 When was the last time you had trouble with "static"? Can you show a 
 snippet of code that's confusing because of it?


"not having a trouble" and "not being consistant" are two different things.

For example, I have no trouble with ".." meaning exclusive range inside a
'[' ']' pair, and an inclusive range in a 'case' statement. That does not
trouble me at all and yet it is an inconsistancy.

But back to your question ... here is 'static' used with three different
meanings within three lines of code.

-------
module xyzzy;
import std.stdio;

version(X) const int y = 1;
else       const int y = -1;
           
static this() {
   static if (y == 1) 
      static int x = 0;
   else
      static int x = 42;
 
   writefln("X=%d Y=%d", x,y);
}

void main()
{
   
}

----------

But maybe that's just me?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:

 But back to your question ... here is 'static' used with three different
 meanings within three lines of code.
 
 -------
 module xyzzy;
 import std.stdio;
 
 version(X) const int y = 1;
 else       const int y = -1;
            
 static this() {
    static if (y == 1) 
       static int x = 0;
    else
       static int x = 42;
  
    writefln("X=%d Y=%d", x,y);
 }
 
 void main()
 {
    
 }
 
 ----------
 
 But maybe that's just me?


Doesn't confuse me one bit.

Andrei
May 18 2009
parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:05:03 -0500, Andrei Alexandrescu wrote:


 Derek Parnell wrote:

 But back to your question ... here is 'static' used with three different
 meanings within three lines of code.
 
 -------
 module xyzzy;
 import std.stdio;
 
 version(X) const int y = 1;
 else       const int y = -1;
            
 static this() {
    static if (y == 1) 
       static int x = 0;
    else
       static int x = 42;
  
    writefln("X=%d Y=%d", x,y);
 }
 
 void main()
 {
    
 }
 
 ----------
 
 But maybe that's just me?


 
 Doesn't confuse me one bit.


That's nice.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:

 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.


 So your argument is that "case" inherently deserves a special case?


 
 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing", and the most
 useful thing for switches is inclusive.


No! If I thought that, I would have said this is fine:

case 'a' .. 'z':

It is NOT fine because 'a' .. 'z' means one thing here and a different 
thing in another place. So I went for:

case 'a': .. case 'z':

specifically because case 'a': .. case 'z': does NOT have any meaning 
anywhere else.


Andrei
May 18 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 5:33 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:

 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.


 So your argument is that "case" inherently deserves a special case?


 Thinking about it more, I guess you must actually be seeing it as a
 rule of =A0 " '..' always does the most useful thing", and the most
 useful thing for switches is inclusive.


 No! If I thought that, I would have said this is fine:

 case 'a' .. 'z':

 It is NOT fine because 'a' .. 'z' means one thing here and a different th=


ing

 in another place. So I went for:

 case 'a': .. case 'z':

 specifically because case 'a': .. case 'z': does NOT have any meaning
 anywhere else.


Well, I'm floored that you find that at all elegant.  It's "elegant"
in much the same way using static to mean 12 different things,
depending upon context, is "elegant".   Although here it's worse I'd
say because the meaning is so much closer to the other meaning, so the
expectation of matching behavior is greater.  But maybe you dig on
that kind of thing.  I see it as a necessary evil.  Not something to
go strutting around proudly about.

Dat's all I'm gonna say about it though.  I've had my fill on this one.

--bb
May 18 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gusuoi$ftk$2 digitalmars.com...

 No! If I thought that, I would have said this is fine:

 case 'a' .. 'z':

 It is NOT fine because 'a' .. 'z' means one thing here and a different 
 thing in another place. So I went for:

 case 'a': .. case 'z':

 specifically because case 'a': .. case 'z': does NOT have any meaning 
 anywhere else.


After reading that over and over many times, I think I finally see what you 
were trying to get at with that. People are supposed to see that as:

case 'a': case 'b': case 'c': /*snipped, but you get the idea*/ case 'x': 
case 'y': case 'z':

And everything except the first and last is just "shrunk down". I think I 
understand how that can be seen as elegance.

But others have brought up some very valid objections that I really have to 
agree with, and I'll add one more: A lot of people don't like the whole 
"fall-through" thing anyway and want to see D move farther from it rather 
than embracing it as this syntax seems to do.
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:gusuoi$ftk$2 digitalmars.com...

 No! If I thought that, I would have said this is fine:

 case 'a' .. 'z':

 It is NOT fine because 'a' .. 'z' means one thing here and a different 
 thing in another place. So I went for:

 case 'a': .. case 'z':

 specifically because case 'a': .. case 'z': does NOT have any meaning 
 anywhere else.


 
 After reading that over and over many times, I think I finally see what you 
 were trying to get at with that. People are supposed to see that as:
 
 case 'a': case 'b': case 'c': /*snipped, but you get the idea*/ case 'x': 
 case 'y': case 'z':
 
 And everything except the first and last is just "shrunk down". I think I 
 understand how that can be seen as elegance.


Yes. I got a rush of endorphine out of that one.


 But others have brought up some very valid objections that I really have to 
 agree with, and I'll add one more: A lot of people don't like the whole 
 "fall-through" thing anyway and want to see D move farther from it rather 
 than embracing it as this syntax seems to do.


I dislike the fall through as much as you do.


Andrei
May 18 2009
parent grauzone <none example.net> writes:
 I dislike the fall through as much as you do.


What about fixing it?

My proposal was always to introduce a new, second syntax, which switches 
to sane semantics:

switch (x) {
    case(value) {
       //no fall through
    }
    case value2:
       //C compatibility, fall through
}

At least the colon should make the two syntaxes [proper plural?] 
unambiguous.
May 18 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Bill Baxter wrote:

 On Mon, May 18, 2009 at 4:15 PM, Bill Baxter <wbaxter gmail.com> wrote:

 But it's not "blarf". It's "case". I am floored that nobody sees the
 elegance of that syntax.


 So your argument is that "case" inherently deserves a special case?


 Thinking about it more, I guess you must actually be seeing it as a
 rule of   " '..' always does the most useful thing", and the most
 useful thing for switches is inclusive.


 
 No! If I thought that, I would have said this is fine:
 
 case 'a' .. 'z':
 
 It is NOT fine because 'a' .. 'z' means one thing here and a different 
 thing in another place. So I went for:
 
 case 'a': .. case 'z':
 
 specifically because case 'a': .. case 'z': does NOT have any meaning 
 anywhere else.


The colon is not needed there for understanding, and definitely not 
needed for remembering that .. in a case is inclusive. It's the overall 
context (being in a switch statement) that puts the programmer in the 
inclusive mindset.

     case 'a' .. case 'z':

is adequate. Besides, then we can have discontinuous ranges without 
changing the current behavior, since

     case 'a' .. case 'z':
     case 'A' .. case 'Z':
         do something

is the same as

     case 'a' .. case 'z': case 'A' .. case 'Z':
         do something

already now.
May 18 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 Bill Baxter wrote:

 On Mon, May 18, 2009 at 3:29 PM, Jason House
 <jason.james.house gmail.com> wrote:
 

 It's all a matter of perspective. I see both as begin .. end. That may be the
same reason why I think addition when I see foo(bar()) + baz(37). The extra
cruft is more or less ignored when figuring out the basics of what is going on.


 
 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".


 
 But it's not "blarf". It's "case". I am floored that nobody sees the 
 elegance of that syntax.
 
 Andrei


I don't know if it's a consolation or throwing salt in your eyes, but I still
don't see the elegance of using the keyword for an enumerated set to represent
manifest constants.
May 18 2009
parent "Nick Sabalausky" <a a.a> writes:
"Jason House" <jason.james.house gmail.com> wrote in message 
news:gusvsq$i81$1 digitalmars.com...

 I don't know if it's a consolation or throwing salt in your eyes, but I 
 still don't see the elegance of using the keyword for an enumerated set to 
 represent manifest constants.


As a testament to the sucky-ness of "enum manifst constants", even though 
I've been seeing discussions about it for years, there hasn't been a single 
time where it's actually occurred to me to use it. Anytime I write in D, I 
still just keep using "const" instead of "enum" to creat my 
...*constants*... without even thinking about it.
May 18 2009
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Bill Baxter wrote:

 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".


Agreed.

Although non-inclusive ranges are common enough that they deserve their
own syntax, I think inclusive ranges are *also* important enough to
deserve their own syntax.  Writing '+1' is often error-prone or even
just plain wrong (such as when it leads to integer overflow).

I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
and similar to 'a .. b' without being too similar.  It does require the
programmer to pay attention, but that's unavoidable.  From there, it
naturally follows that 'case's in a 'switch' statement should follow the
same convention.

I don't believe it makes any sense to have inclusive ranges in 'switch'
statements and non-inclusive ranges everywhere else.  Inclusive ranges
are fairly common outside 'switch' statements, and non-inclusive ranges
are fairly common in 'switch' statements.


-- 
Rainer Deyke - rainerd eldwood.com
May 18 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Rainer Deyke wrote:

 Bill Baxter wrote:

 Agreed.  If you tell someone   a .. b  means a non-inclusive range
 from a to b, then ask them to guess what    blarf a .. blarf b  means,
 I would be very surprised if many guessed "inclusive range from blarf
 a  to blarf b".


 
 Agreed.
 
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax.  Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).
 
 I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
 and similar to 'a .. b' without being too similar.


I swear I didn't see the difference til the third read. I thought you 
were kidding.

Even Perl would turn its nose at a significant semantic difference 
brought by the third period.


Andrei
May 18 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.


Not true: Perl has a '..' operator and a '...' operator with distinct
but similar meanings.  And as much as I loathe Perl in general, I don't
see anything wrong with that.  I am open to a reasonable alternate syntax.


-- 
Rainer Deyke - rainerd eldwood.com
May 18 2009
next sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Rainer Deyke wrote:

 Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.


 
 Not true: Perl has a '..' operator and a '...' operator with distinct
 but similar meanings.  And as much as I loathe Perl in general, I don't
 see anything wrong with that.  I am open to a reasonable alternate syntax.


Having both .. and ... wouldn't be too bad. They're insistinguishable 
only as long as one is not expecting a distinction. But with a 
programming language, they look dissimilar enough.

A side benefit would be to be able to specify inclusive and exclusive 
ranges both within switch statements and range contexts.

'0' ... '9'
'a' ... 'z'
a .. b
a ... b
0 .. middle
middle .. $

Of course, this idea will be drowned in a 2-month bicycle shed color 
discussion about which should be the inclusive range and which the 
exclusive one. And after that somebody suggests tokens for the remaining 
two inclusion permutations, and then we really can forget all this for good.
May 18 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Georg Wrede wrote:

 Rainer Deyke wrote:

 Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.


 Not true: Perl has a '..' operator and a '...' operator with distinct
 but similar meanings.  And as much as I loathe Perl in general, I don't
 see anything wrong with that.  I am open to a reasonable alternate 
 syntax.


 
 Having both .. and ... wouldn't be too bad. They're insistinguishable 
 only as long as one is not expecting a distinction. But with a 
 programming language, they look dissimilar enough.
 
 A side benefit would be to be able to specify inclusive and exclusive 
 ranges both within switch statements and range contexts.
 
 '0' ... '9'
 'a' ... 'z'
 a .. b
 a ... b
 0 .. middle
 middle .. $
 
 Of course, this idea will be drowned in a 2-month bicycle shed color 
 discussion about which should be the inclusive range and which the 
 exclusive one. And after that somebody suggests tokens for the remaining 
 two inclusion permutations, and then we really can forget all this for 
 good.


I'm now sorry I even mentioned the blessed thing. This must have been 
the worst discussion on language design, ever.

Andrei
May 18 2009
next sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 23:09:21 -0500, Andrei Alexandrescu wrote:


 I'm now sorry I even mentioned the blessed thing. This must have been 
 the worst discussion on language design, ever.


LOL ... especially when these discussions have no influence on whatever the
outcome will eventually be.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
prev sibling parent Georg Wrede <georg.wrede iki.fi> writes:
Andrei Alexandrescu wrote:

 Georg Wrede wrote:

 Rainer Deyke wrote:

 Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.


 Not true: Perl has a '..' operator and a '...' operator with distinct
 but similar meanings.  And as much as I loathe Perl in general, I don't
 see anything wrong with that.  I am open to a reasonable alternate 
 syntax.


 Having both .. and ... wouldn't be too bad. They're insistinguishable 
 only as long as one is not expecting a distinction. But with a 
 programming language, they look dissimilar enough.

 A side benefit would be to be able to specify inclusive and exclusive 
 ranges both within switch statements and range contexts.

 '0' ... '9'
 'a' ... 'z'
 a .. b
 a ... b
 0 .. middle
 middle .. $

 Of course, this idea will be drowned in a 2-month bicycle shed color 
 discussion about which should be the inclusive range and which the 
 exclusive one. And after that somebody suggests tokens for the 
 remaining two inclusion permutations, and then we really can forget 
 all this for good.


 
 I'm now sorry I even mentioned the blessed thing. This must have been 
 the worst discussion on language design, ever.


I was only half serious. :-)
May 18 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 8:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:

 Andrei Alexandrescu wrote:

 Even Perl would turn its nose at a significant semantic difference
 brought by the third period.


 Not true: Perl has a '..' operator and a '...' operator with distinct
 but similar meanings. =A0And as much as I loathe Perl in general, I don't
 see anything wrong with that. =A0I am open to a reasonable alternate synt=


ax.

Heh, right you are.
http://www.perl.com/doc/manual/html/pod/perlop.html#Range_Operators

If Ruby won't turn it's nose up at a two dot /  three dot distinction,
then it would be hard to believe Perl would.

But leave it to Perl to give it a completely obscure meaning.

--bb
May 18 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:


 Bill Baxter wrote:
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax.  Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).


Agreed.


 I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
 and similar to 'a .. b' without being too similar.  It does require the
 programmer to pay attention, but that's unavoidable.  From there, it
 naturally follows that 'case's in a 'switch' statement should follow the
 same convention.


Sorry, but I don't share your sense of "easy to read" here. The eye can
glaze over the third dot very easily and just not notice it.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, May 18, 2009 at 8:48 PM, Derek Parnell <derek psych.ward> wrote:

 On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:


 Bill Baxter wrote:
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax. =A0Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).


 Agreed.


 I favor the syntax 'a ... b' for inclusive ranges. =A0It's easy to read
 and similar to 'a .. b' without being too similar. =A0It does require th=




e

 programmer to pay attention, but that's unavoidable. =A0From there, it
 naturally follows that 'case's in a 'switch' statement should follow the
 same convention.


 Sorry, but I don't share your sense of "easy to read" here. The eye can
 glaze over the third dot very easily and just not notice it.


That's often said, but if you're looking at it in a fixed-width font,
then I don't agree that it's so easy to glaze over the third dot.

--bb
May 18 2009
prev sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Derek Parnell Wrote:


 On Mon, 18 May 2009 20:05:14 -0600, Rainer Deyke wrote:
 

 Bill Baxter wrote:
 Although non-inclusive ranges are common enough that they deserve their
 own syntax, I think inclusive ranges are *also* important enough to
 deserve their own syntax.  Writing '+1' is often error-prone or even
 just plain wrong (such as when it leads to integer overflow).


 
 Agreed.
 

 I favor the syntax 'a ... b' for inclusive ranges.  It's easy to read
 and similar to 'a .. b' without being too similar.  It does require the
 programmer to pay attention, but that's unavoidable.  From there, it
 naturally follows that 'case's in a 'switch' statement should follow the
 same convention.


 
 Sorry, but I don't share your sense of "easy to read" here. The eye can
 glaze over the third dot very easily and just not notice it.
 
 -- 
 Derek Parnell
 Melbourne, Australia
 skype: derek.j.parnell


I disagree, the ... syntax was also my suggestion for the reason that it is a
very obvious syntax that isn't limited to only the switch ranges.

I don't think its that easy to miss a third dot, especially if there are spaces
around the operator, and the editor uses a fixed-width font (like any good
editor should).

If you want to be paranoid about confusion, comment it, just like closing }'s
are often seen with a comment of the opening statement, just like you would do:
} // version(Windows)
you can do:
case 1 ... 10: // inclusive

You could also configure your editor to color code them differently, I already
do that with a lot of other things, it gives the brain one more cue  to detect
what is going on.

And since the operator also leaves .. available for inclusive ranges you can do:
case FIRST .. LAST + 1:

or even better:
enum CASE_LAST = LAST + 1:
case FIRST .. CASE_LAST:

This goes along with the best feature of D: let the programmers do things the
way they want to.
May 18 2009
prev sibling next sibling parent Jason House <jason.james.house gmail.com> writes:
 

 On a similar note, Andrei, what is this spree of removing features? Ok some
 are obviously bad, imaginary types for example, but why remove other stuff
 such as commplex and with?


 
 TDPL is coming out. This is quite literally the last chance to shed some 
 old skin. Complex as a built-in does nothing of interest to anyone 
 except a cute syntax for literals that nobody uses (how many remarkable 
 complex literals could you imagine?) About "with"... see above before I 
 die of a heart attack.
 
 The baroque "!<>=" operators became much more attractive since Walter 
 said he's considering making them overloadable.
 
 On the other hand new features are coming, which I believe are "good 
 skin". Narrowing integral conversions will go. Walter is working on a 
 very cool scheme for inferring the range of expressions that makes casts 
 unnecessary in many cases.


Can you give us more detail?


 Casts are a plague not only for safe code, 
 but also for generic code that wants to be scalable and change-robust. 


I'm still hoping that one day D will be able to implicitly cast to scope
invariant... such as when calling pure functions with non-shared data.

On an almost unrelated note, D currently makes it far too easy to share
non-shared data. Kicking off threads with non-unique unshared data is unsafe
but works without casting. That really should get fixed.


 The ease with which C and C++ allow losing state and the drowning 

 happy to see D avoid.
May 18 2009
prev sibling next sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Andrei Alexandrescu wrote:

 I personally still think it's a bad feature because it introduces
 long-distance coupling between symbols defined in two different places,
 both distinct from the place where the statement is used! Consider:
 
 import wyda;  // defines symbol write
 import geeba; // defines struct S { ... }
 
 void main()
 {
     S s;
     with (s) {
        write(5);
     }
 }
 
 Machiavelly would jump in joy at such code. What did I achieve? I saved
 a few "s.". What did I lose? The ability so say anything, but absolutely
 anything on what the code does. 


I understand the problem you are pointing out even if I don't belive it's a
significant issue. The problem with your assumption that it saves  a few 
"s." is that where I usualy use it is in cases like this.

with(listofdecentlysizedstructs[i].vector3d){
        return x*x+y*y+z*z;
}

Maybe not an ideal example, usualy I have several lines of math algorithms
or physics formula in the with scope. The gain here is both that I dont
have to type long variable names (could be solved with an alias maybe) but
more importantly it allows me to keep pysics and math formula close to the
form they have in math or pysics. For example writing x y and z for the
parts of some point I'm currently working on instead of p[i].x p[i].y and
p[i].z can in a formula with lots of them make the code easier to read. For
a single use of symbols I see no important use of the with statement.
May 19 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
bearophile Wrote:

Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


That's a real pity.

I had a lot of respect for you and your perpetual inclusion of the D community
(both announcing features and getting design feedback). 

Very early on in this thread, it became obvious to me that too much of it was
getting under your skin. I've lost count of the insults posted in this thread.
We're all trying to make D the best language we can, even if we come from
vastly different perspectives.
May 20 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:

 bearophile Wrote:
 
 Andrei Alexandrescu:

 I don't plan to discuss minor features on this group anymore.


 
 That's a real pity.
 
 I had a lot of respect for you and your perpetual inclusion of the D
 community (both announcing features and getting design feedback).
 
 Very early on in this thread, it became obvious to me that too much
 of it was getting under your skin. I've lost count of the insults
 posted in this thread. We're all trying to make D the best language
 we can, even if we come from vastly different perspectives.


I am sorry I have gotten on the wrong side of civility in this thread.

Andrei
May 20 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 17 May 2009 19:33:35 -0500, Andrei Alexandrescu wrote:


 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }


I guess the reason for using with() is to avoid typing repetitive stuff.
Would this work instead ...


 int x, y;
 with (p as "somevery.long.struct.or.class[17].name")
 {
      y += p.x;
      ++p.x;
 }

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 17 2009
next sibling parent reply grauzone <none example.net> writes:
Derek Parnell wrote:

 On Sun, 17 May 2009 19:33:35 -0500, Andrei Alexandrescu wrote:
 

 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:

 int x, y;
 with (whatever)
 {
      y += x;
      ++x;
 }




I agree.


 I guess the reason for using with() is to avoid typing repetitive stuff.
 Would this work instead ...
 
 
  int x, y;
  with (p as "somevery.long.struct.or.class[17].name")
  {
       y += p.x;
       ++p.x;
  }
 


You could as well use auto and a block without statement before it to 
set the scope. But that'd look kind of ugly. A block without statement 
looks like you forgot an if.

Here's another simple fix for with();

int x, y;
with (whatever)
{
       .y += x; //.y references this is whatever.y
       ++x;     //x references local scope
}
May 17 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"grauzone" <none example.net> wrote in message 
news:guqrj2$2l7h$2 digitalmars.com...

 Here's another simple fix for with();

 int x, y;
 with (whatever)
 {
       .y += x; //.y references this is whatever.y
       ++x;     //x references local scope
 }


That already means global scope.
May 18 2009
parent reply grauzone <none example.net> writes:
Nick Sabalausky wrote:

 "grauzone" <none example.net> wrote in message 
 news:guqrj2$2l7h$2 digitalmars.com...

 Here's another simple fix for with();

 int x, y;
 with (whatever)
 {
       .y += x; //.y references this is whatever.y
       ++x;     //x references local scope
 }


 
 That already means global scope. 


Yes, but who uses that anyway?
May 18 2009
parent Christopher Wright <dhasenan gmail.com> writes:
grauzone wrote:

 Nick Sabalausky wrote:

 "grauzone" <none example.net> wrote in message 
 news:guqrj2$2l7h$2 digitalmars.com...

 Here's another simple fix for with();

 int x, y;
 with (whatever)
 {
       .y += x; //.y references this is whatever.y
       ++x;     //x references local scope
 }


 That already means global scope. 


 
 Yes, but who uses that anyway?


There's that perennial annoyance that class methods with a given name 
hide free functions of the same name, even if they are not covariant. 
This crops up a lot with toString, and the fix is to prepend a dot to 
the invocation.
May 18 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Derek Parnell wrote:

 
 I guess the reason for using with() is to avoid typing repetitive stuff.
 Would this work instead ...
 
 
  int x, y;
  with (p as "somevery.long.struct.or.class[17].name")
  {
       y += p.x;
       ++p.x;
  }


{
     ref p = somevery.long.struct.or.class[17].name;
     y += p.x;
     ++p.x;
}
May 18 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:


 {
      ref p = somevery.long.struct.or.class[17].name;
      y += p.x;
      ++p.x;
 }


{
     alias somevery.long.struct.or.class[17].name p;
     y += p.x;
     ++p.x;
}

Or:

{
     alias somevery.long.struct.or.class[17].name as p;
     y += p.x;
     ++p.x;
}

Or nicer:

alias somevery.long.struct.or.class[17].name as p {
     y += p.x;
     ++p.x;
}

Bye,
bearophile
May 18 2009
parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 12:59:08 -0400, bearophile wrote:


 Or nicer:
 
 alias somevery.long.struct.or.class[17].name as p {
      y += p.x;
      ++p.x;
 }


Yeah, that's nice too.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 18 May 2009 09:55:42 -0700, Sean Kelly wrote:


 Derek Parnell wrote:

 
 I guess the reason for using with() is to avoid typing repetitive stuff.
 Would this work instead ...
 
  int x, y;
  with (p as "somevery.long.struct.or.class[17].name")
  {
       y += p.x;
       ++p.x;
  }


 
 {
      ref p = somevery.long.struct.or.class[17].name;
      y += p.x;
      ++p.x;
 }


Yes that would work too, and probably better code generation too.

The difference being that my suggestion is a compile-time behaviour and
yours is a run time behaviour.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 18 2009
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Andrei Alexandrescu wrote:

 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
     y += x;
     ++x;
 }
 
 What can be said about such code? Nothing. If whatever has or will ever 
 have fields x or y or both, the names will bind to them; otherwise, 
 they'll bind to the locals. Non-local code dependency at its finest.
 
 Maintenance of any type that is being used with "with" becomes a very 
 dangerous proposition because it can silently change meaning of code.
 
 I therefore submit that "with" is an extremely dangerous feature and 
 should be removed from the language. What say you?



I agree, "with" makes code difficult to read. If one really wants to 
avoid typing, just use alias:

    alias my.very.long.string.of.symbols x;
    a = x.foo;
    x.foo = b;

This works with lvalues as well.

-Lars
May 18 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:


 f one really wants to avoid typing, just use alias:
     alias my.very.long.string.of.symbols x;
     a = x.foo;
     x.foo = b;


See my suggestion (where there's a p instead of s:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=90439

Bye,
bearophile
May 18 2009
parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
bearophile wrote:

 Lars T. Kyllingstad:
 

 f one really wants to avoid typing, just use alias:
     alias my.very.long.string.of.symbols x;
     a = x.foo;
     x.foo = b;


 
 See my suggestion (where there's a p instead of s:
 http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=90439
 
 Bye,
 bearophile


Sorry, I didn't see that you had already made the suggestion.

I don't think there is any need to extend the alias syntax, though. If 
you only want the alias to work in a limited scope, just enclose it in one:

     int x, y;
     {
         alias another.very.long.name s;
         y += s.x;
         s.x = x;
     }
     s.x = 1; // Doesn't work, s is not in scope.



-Lars
May 18 2009
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Andrei Alexandrescu wrote:


 I therefore submit that "with" is an extremely dangerous feature and  
 should be removed from the language. What say you?


I say 'with' is useful, but (as you say) dangerous. I believe this could be
fixed by requiring an alias inside the parentheses.
This way, code would look like this:

with (alias foo.bar baz) {
  baz.x = y;
}

--
Simen
May 18 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu wrote:

 I think "with" is a very dangerous feature due to the way it hides 
 symbols. It essentially makes the feeblest attempt at modular reasoning 
 utterly impossible:
 
 int x, y;
 with (whatever)
 {
     y += x;
     ++x;
 }


"with" is a useless feature and a waste of a keyword.  I'd love to get 
rid of it.
May 18 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 18 May 2009 20:45:26 +0400, Sean Kelly <sean invisibleduck.org> wrote:


 Andrei Alexandrescu wrote:

 I think "with" is a very dangerous feature due to the way it hides  
 symbols. It essentially makes the feeblest attempt at modular reasoning  
 utterly impossible:
  int x, y;
 with (whatever)
 {
     y += x;
     ++x;
 }


 "with" is a useless feature and a waste of a keyword.  I'd love to get  
 rid of it.


Same here. I don't remember myself using it ever.
May 18 2009