www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static try?

reply Mehrdad <wfunction hotmail.com> writes:
I've written this piece of code a fair number of times:

      static if (is(typeof(foo()))) { foo(); }
      else { bar(); }

When the expression inside the condition (i.e. the call to foo()) gets 
complicated, you get lots of code duplication and things become harder 
to read.

So I'm thinking, why not just introduce a 'static try'?

Something like:

     static try
     {
         foo();
     }
     catch  // (string ex)  // perhaps let them know what the error is?
     {
         bar();
     }

It's a clean and immensely readable improvement IMO, and it doesn't 
introduce any new keywords or any breaking changes to anything.

How's the idea?
Oct 30 2011
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 31/10/2011 02:21, Mehrdad a écrit :
 I've written this piece of code a fair number of times:

 static if (is(typeof(foo()))) { foo(); }
 else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder
 to read.

 So I'm thinking, why not just introduce a 'static try'?

 Something like:

 static try
 {
 foo();
 }
 catch // (string ex) // perhaps let them know what the error is?
 {
 bar();
 }

 It's a clean and immensely readable improvement IMO, and it doesn't
 introduce any new keywords or any breaking changes to anything.

 How's the idea?

That sound dangerous. You can get some compile error and not notice it.
Oct 31 2011
parent reply Mehrdad <wfunction hotmail.com> writes:
On 10/31/2011 4:16 AM, deadalnix wrote:
 Le 31/10/2011 02:21, Mehrdad a écrit :
 I've written this piece of code a fair number of times:

 static if (is(typeof(foo()))) { foo(); }
 else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder
 to read.

 So I'm thinking, why not just introduce a 'static try'?

 Something like:

 static try
 {
 foo();
 }
 catch // (string ex) // perhaps let them know what the error is?
 {
 bar();
 }

 It's a clean and immensely readable improvement IMO, and it doesn't
 introduce any new keywords or any breaking changes to anything.

 How's the idea?

That sound dangerous. You can get some compile error and not notice it.

we're already doing all over the place?
Oct 31 2011
parent deadalnix <deadalnix gmail.com> writes:
Le 31/10/2011 23:29, Mehrdad a écrit :
 On 10/31/2011 4:16 AM, deadalnix wrote:
 Le 31/10/2011 02:21, Mehrdad a écrit :
 I've written this piece of code a fair number of times:

 static if (is(typeof(foo()))) { foo(); }
 else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder
 to read.

 So I'm thinking, why not just introduce a 'static try'?

 Something like:

 static try
 {
 foo();
 }
 catch // (string ex) // perhaps let them know what the error is?
 {
 bar();
 }

 It's a clean and immensely readable improvement IMO, and it doesn't
 introduce any new keywords or any breaking changes to anything.

 How's the idea?

That sound dangerous. You can get some compile error and not notice it.

we're already doing all over the place?

At least, this if(is(typeof())) isn't executed and isn't supposed to be executed. Here you just created a piece of code that you don't know if it will be executed and that will silently fail with no error message. It remind me INTERCAL and it's styupid comment mecanism (at least, it was intentionnaly stupid with INTERCAL) : http://en.wikipedia.org/wiki/INTERCAL
Nov 02 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 30 Oct 2011 21:21:58 -0400, Mehrdad <wfunction hotmail.com> wrote:

 I've written this piece of code a fair number of times:

       static if (is(typeof(foo()))) { foo(); }
       else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder
 to read.

 So I'm thinking, why not just introduce a 'static try'?

 Something like:

      static try
      {
          foo();
      }
      catch  // (string ex)  // perhaps let them know what the error is?
      {
          bar();
      }

 It's a clean and immensely readable improvement IMO, and it doesn't
 introduce any new keywords or any breaking changes to anything.

 How's the idea?

Vote++
Nov 01 2011
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 31.10.2011 02:21, schrieb Mehrdad:
 I've written this piece of code a fair number of times:

        static if (is(typeof(foo()))) { foo(); }
        else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder
 to read.

 So I'm thinking, why not just introduce a 'static try'?

 Something like:

       static try
       {
           foo();
       }
       catch  // (string ex)  // perhaps let them know what the error is?
       {
           bar();
       }

 It's a clean and immensely readable improvement IMO, and it doesn't
 introduce any new keywords or any breaking changes to anything.

 How's the idea?

1. sorry but look like static exception based flow control - because of the "try/catch" - and that is evil 2. static try { } introduces an compiletime scope - what would the following code mean? static try { int x = 10; foo(); int y = 20; } catch { bar(); }
Nov 01 2011
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tue, 01 Nov 2011 18:33:56 +0200, dennis luehring <dl.soluz gmx.net>  
wrote:

 introduces an compiletime scope - what would the following code mean?

"debug", "version", "static if" don't create scopes. -- Best regards, Vladimir mailto:vladimir thecybershadow.net
Nov 01 2011
parent dennis luehring <dl.soluz gmx.net> writes:
Am 01.11.2011 17:46, schrieb Vladimir Panteleev:
 On Tue, 01 Nov 2011 18:33:56 +0200, dennis luehring<dl.soluz gmx.net>
 wrote:

  introduces an compiletime scope - what would the following code mean?

"debug", "version", "static if" don't create scopes.

i know - wrong name for the block between the try{...} static try { ------------------ foo1(); foo2(); foo3(); ------------------ } catch { bar(); } im missing a description of what should happen if any of the foos fails to compile? is then the catch part used in compilation? the idea is too near to the syntax of the exceptionhandling and have total different semantic... is that good?
Nov 01 2011
prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
--1;

It you want to reduce duplication of long code, you can use string mixin.
enum code =3D q{ ...long code... };
static if (is(typeof({ mixin(code); })))
{
  mixin(code);
}
else
{
  ...
}

Kenji Hara

2011/10/31 Mehrdad <wfunction hotmail.com>:
 I've written this piece of code a fair number of times:

 =A0 =A0 static if (is(typeof(foo()))) { foo(); }
 =A0 =A0 else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder to
 read.

 So I'm thinking, why not just introduce a 'static try'?

 Something like:

 =A0 =A0static try
 =A0 =A0{
 =A0 =A0 =A0 =A0foo();
 =A0 =A0}
 =A0 =A0catch =A0// (string ex) =A0// perhaps let them know what the error=

 =A0 =A0{
 =A0 =A0 =A0 =A0bar();
 =A0 =A0}

 It's a clean and immensely readable improvement IMO, and it doesn't
 introduce any new keywords or any breaking changes to anything.

 How's the idea?

Nov 01 2011
parent reply bcs <bcs example.com> writes:
On 11/01/2011 10:04 AM, kenji hara wrote:
 --1;

 It you want to reduce duplication of long code, you can use string mixin.
 enum code = q{ ...long code... };
 static if (is(typeof({ mixin(code); })))
 {
    mixin(code);
 }
 else
 {
    ...
 }

Please no! I've thought for years that string mixins are seriously overused in D. IMnsHO they should only be used as a method of last resort. For every case I've seen where there is a alternative to a string mixin, the alternative was cleaner. If people don't like the static try/catch, how about: static try/else?
 Kenji Hara

 2011/10/31 Mehrdad<wfunction hotmail.com>:
 I've written this piece of code a fair number of times:

      static if (is(typeof(foo()))) { foo(); }
      else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder to
 read.

 So I'm thinking, why not just introduce a 'static try'?

 Something like:

     static try
     {
         foo();
     }
     catch  // (string ex)  // perhaps let them know what the error is?
     {
         bar();
     }

 It's a clean and immensely readable improvement IMO, and it doesn't
 introduce any new keywords or any breaking changes to anything.

 How's the idea?


Nov 01 2011
parent reply Don <nospam nospam.com> writes:
On 02.11.2011 03:57, bcs wrote:
 On 11/01/2011 10:04 AM, kenji hara wrote:
 --1;

 It you want to reduce duplication of long code, you can use string mixin.
 enum code = q{ ...long code... };
 static if (is(typeof({ mixin(code); })))
 {
 mixin(code);
 }
 else
 {
 ...
 }

Please no! I've thought for years that string mixins are seriously overused in D. IMnsHO they should only be used as a method of last resort. For every case I've seen where there is a alternative to a string mixin, the alternative was cleaner. If people don't like the static try/catch, how about: static try/else?

Probably worth noting that in the latest release, you can instantiate a template from inside an is(typeof()), and if it fails to compile, the template instantiation will be discarded. (Prior to 2.056, if the template instantiation failed, compilation would fail). This means you can now factor out "does it compile?" tests into a template, to reduce code duplication.
Nov 02 2011
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 02/11/2011 08:24, Don a écrit :
 On 02.11.2011 03:57, bcs wrote:
 On 11/01/2011 10:04 AM, kenji hara wrote:
 --1;

 It you want to reduce duplication of long code, you can use string
 mixin.
 enum code = q{ ...long code... };
 static if (is(typeof({ mixin(code); })))
 {
 mixin(code);
 }
 else
 {
 ...
 }

Please no! I've thought for years that string mixins are seriously overused in D. IMnsHO they should only be used as a method of last resort. For every case I've seen where there is a alternative to a string mixin, the alternative was cleaner. If people don't like the static try/catch, how about: static try/else?

Probably worth noting that in the latest release, you can instantiate a template from inside an is(typeof()), and if it fails to compile, the template instantiation will be discarded. (Prior to 2.056, if the template instantiation failed, compilation would fail). This means you can now factor out "does it compile?" tests into a template, to reduce code duplication.

This look like a cleaner solution.
Nov 02 2011
prev sibling parent bcs <bcs example.com> writes:
On 11/02/2011 12:24 AM, Don wrote:
 On 02.11.2011 03:57, bcs wrote:
 On 11/01/2011 10:04 AM, kenji hara wrote:
 --1;

 It you want to reduce duplication of long code, you can use string
 mixin.
 enum code = q{ ...long code... };
 static if (is(typeof({ mixin(code); })))
 {
 mixin(code);
 }
 else
 {
 ...
 }

Please no! I've thought for years that string mixins are seriously overused in D. IMnsHO they should only be used as a method of last resort. For every case I've seen where there is a alternative to a string mixin, the alternative was cleaner. If people don't like the static try/catch, how about: static try/else?

Probably worth noting that in the latest release, you can instantiate a template from inside an is(typeof()), and if it fails to compile, the template instantiation will be discarded. (Prior to 2.056, if the template instantiation failed, compilation would fail). This means you can now factor out "does it compile?" tests into a template, to reduce code duplication.

That still has the (potential) issue of putting the code out-of-line.
Nov 02 2011
prev sibling parent reply Don <nospam nospam.com> writes:
On 31.10.2011 02:21, Mehrdad wrote:
 I've written this piece of code a fair number of times:

 static if (is(typeof(foo()))) { foo(); }
 else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder
 to read.

IMHO the only problem is the is(typeof()) syntax. Otherwise I don't see how this has any more code duplication than: if( foo(lots_of_parameters) ) foo(lots_of_parameters); else bar();
Nov 01 2011
parent reply Mehrdad <wfunction hotmail.com> writes:
On 11/1/2011 11:55 PM, Don wrote:
 On 31.10.2011 02:21, Mehrdad wrote:
 I've written this piece of code a fair number of times:

 static if (is(typeof(foo()))) { foo(); }
 else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder
 to read.

IMHO the only problem is the is(typeof()) syntax. Otherwise I don't see how this has any more code duplication than: if( foo(lots_of_parameters) ) foo(lots_of_parameters); else bar();

sorry but I'm confused as how that's related to static try/catch...
Nov 02 2011
parent Don <nospam nospam.com> writes:
On 02.11.2011 09:38, Mehrdad wrote:
 On 11/1/2011 11:55 PM, Don wrote:
 On 31.10.2011 02:21, Mehrdad wrote:
 I've written this piece of code a fair number of times:

 static if (is(typeof(foo()))) { foo(); }
 else { bar(); }

 When the expression inside the condition (i.e. the call to foo()) gets
 complicated, you get lots of code duplication and things become harder
 to read.

IMHO the only problem is the is(typeof()) syntax. Otherwise I don't see how this has any more code duplication than: if( foo(lots_of_parameters) ) foo(lots_of_parameters); else bar();

sorry but I'm confused as how that's related to static try/catch...

The only benefit you'd get from static try/catch is a small reduction in code duplication, in one specific idiom. I'm arguing that the code duplication is no worse in this case than in anything other case in the language. I'm not seeing why that particular idiom is so phenomenally important that it deserves its own syntax to obtain such a tiny benefit.
Nov 02 2011