On Thursday, 30 June 2016 at 11:06:56 UTC, Steven Schveighoffer
wrote:
On 6/29/16 11:40 AM, Wyatt wrote:
I might be stepping on a land mine by bringing it up, but
isn't this
sort of thing what contracts are for?
No landmines here, but no, that isn't what contracts are for.
Perhaps you mean c
On 6/29/16 11:40 AM, Wyatt wrote:
On Friday, 24 June 2016 at 18:27:07 UTC, Steven Schveighoffer wrote:
void fun(T)(T obj)
{
static if (!hasMember(T, "gun")) throw new Exception("No gun");
obj.gun;
}
Call with something that doesn't have a gun member, and even without
the reachability wa
On Friday, 24 June 2016 at 18:27:07 UTC, Steven Schveighoffer
wrote:
void fun(T)(T obj)
{
static if (!hasMember(T, "gun")) throw new Exception("No
gun");
obj.gun;
}
Call with something that doesn't have a gun member, and even
without the reachability warnings (no -w switch), it doesn'
On Tuesday, June 28, 2016 13:34:48 QAston via Digitalmars-d wrote:
> On Monday, 27 June 2016 at 22:56:41 UTC, Jonathan M Davis wrote:
> > Agreed. The code outside of the static if should be compiled
> > regardless, because it's not part of the static if/else at all
> > and therefore has not been ma
On Tuesday, 28 June 2016 at 21:06:18 UTC, QAston wrote:
On Tuesday, 28 June 2016 at 17:41:58 UTC, deadalnix wrote:
"The solution doesn't solve all problems, therefore the
solution do not make things any better"
Nonsense.
More like "this solution doesn't solve all problems solved by
other s
On Tuesday, 28 June 2016 at 17:41:58 UTC, deadalnix wrote:
"The solution doesn't solve all problems, therefore the
solution do not make things any better"
Nonsense.
More like "this solution doesn't solve all problems solved by
other solution and that's worth keeping in mind".
We already a
On Tuesday, 28 June 2016 at 13:34:48 UTC, QAston wrote:
On Monday, 27 June 2016 at 22:56:41 UTC, Jonathan M Davis wrote:
Agreed. The code outside of the static if should be compiled
regardless, because it's not part of the static if/else at all
and therefore has not been marked as conditionally
On Monday, 27 June 2016 at 22:56:41 UTC, Jonathan M Davis wrote:
Agreed. The code outside of the static if should be compiled
regardless, because it's not part of the static if/else at all
and therefore has not been marked as conditionally compilable.
But if we don't warn about unreachable code
On Monday, 27 June 2016 at 22:56:41 UTC, Jonathan M Davis wrote:
On Monday, June 27, 2016 18:55:48 deadalnix via Digitalmars-d
wrote:
On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
> [...]
Alright, I have to range myself with most here. While I'm all
for not warning about unreachab
On Monday, June 27, 2016 18:55:48 deadalnix via Digitalmars-d wrote:
> On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
> > Me, because that's what it means to evaluate the condition at
> > compile time and only compiling in the appropriate branch. This
> > is additional and special behav
On Monday, 27 June 2016 at 11:05:49 UTC, cym13 wrote:
What's unintuitive about it (real question)? It would make it
behave more like a standard if and early returns are very
common, well understood and good practice:
void func(int* somepointer) {
if (somepointer == null)
return;
On Monday, 27 June 2016 at 11:05:49 UTC, cym13 wrote:
What's unintuitive about it (real question)? It would make it
behave more like a standard if and early returns are very
common, well understood and good practice:
void func(int* somepointer) {
if (somepointer == null)
return;
On Monday, 27 June 2016 at 18:55:48 UTC, deadalnix wrote:
On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
Me, because that's what it means to evaluate the condition at
compile time and only compiling in the appropriate branch.
This is additional and special behaviour and it destroys
On Monday, 27 June 2016 at 18:14:26 UTC, Timon Gehr wrote:
Me, because that's what it means to evaluate the condition at
compile time and only compiling in the appropriate branch. This
is additional and special behaviour and it destroys the
orthogonality of 'static if' and 'return'. (I don't fe
On 27.06.2016 13:05, cym13 wrote:
On Monday, 27 June 2016 at 08:16:18 UTC, Claude wrote:
On Saturday, 25 June 2016 at 11:27:01 UTC, cym13 wrote:
We are talking about early returns (checking for something and
returning as soon as possible) which are a well-known and efficient
way to reduce inden
On Monday, 27 June 2016 at 00:31:39 UTC, Jonathan M Davis wrote:
On Friday, June 24, 2016 13:54:21 Andrei Alexandrescu via
Digitalmars-d wrote:
I would think that it's highly unintuitive to think that code
outside of a static if would be treated as part of an else of a
static if just because
On Monday, 27 June 2016 at 08:16:18 UTC, Claude wrote:
On Saturday, 25 June 2016 at 11:27:01 UTC, cym13 wrote:
We are talking about early returns (checking for something and
returning as soon as possible) which are a well-known and
efficient
way to reduce indentation levels and increase modular
On Saturday, 25 June 2016 at 11:27:01 UTC, cym13 wrote:
We are talking about early returns (checking for something and
returning as soon as possible) which are a well-known and
efficient
way to reduce indentation levels and increase modularity. You
can't
come and say "What? You want it to work?
On Friday, June 24, 2016 13:54:21 Andrei Alexandrescu via Digitalmars-d wrote:
> On 6/24/16 1:15 PM, Steven Schveighoffer wrote:
> > The problem that hasn't been made clear is, why can't you just write:
> >
> > static if(condition)
> > {
> >
> > ... // some code
> > return;
> >
> > }
> >
>
On Sunday, 26 June 2016 at 21:14:16 UTC, QAston wrote:
Also - metaprogramming. You don't know the control flow of
whatever you may be printing in a mixin, or having as a
parameter in a template. Making such code even more difficult
to analyze.
Also, this couples runtime control flow with cond
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
Please no. I'd argue that this brings more confusion than
readibility. Imagine reading more complicated code with this. You
have to
On Saturday, 25 June 2016 at 11:27:01 UTC, cym13 wrote:
We are talking about early returns (checking for something and
returning as soon as possible) which are a well-known and
efficient
way to reduce indentation levels and increase modularity. You
can't
come and say "What? You want it to work?
On Saturday, 25 June 2016 at 10:19:47 UTC, Claude wrote:
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
My 2 cents. I don't find that annoying at all. It's perfectly
normal IMHO.
On Saturday, 25 June 2016 at 10:19:47 UTC, Claude wrote:
And if some code have too many indentation levels, than it
probably means it should be better modularized, hence I'd
suggest to split it in several sub-functions, it will be more
readable/maintainable.
We are talking about early returns
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
My 2 cents. I don't find that annoying at all. It's perfectly
normal IMHO.
It may introduce an additional indentation level for th
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
What I think about enchancement of static if is that it could be
interesting to have `elif` keyword like in Python, so instead of
s
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
please, no. introduce `final static if` or something, but don't
do this with `static if` itself. it makes special case `static
if`
On Friday, 24 June 2016 at 18:27:07 UTC, Steven Schveighoffer
wrote:
Even with this, I still didn't understand. Now with your
example in the bug report, it's clear. Reproducing here:
void fun(T)(T obj)
{
static if (!hasMember(T, "gun")) throw new Exception("No
gun");
obj.gun;
}
Cal
On Friday, 24 June 2016 at 15:43:58 UTC, Stefan Koch wrote:
To elaborate:
This requires control-flow analysis over all static if
branches,
to find and very one special case which we treat specially.
No.
This require to put a maybe reachable flag in some position int
the code (namely, aft
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
I made a proposal for this. Yes it is very annoying.
On 6/24/16 1:54 PM, Andrei Alexandrescu wrote:
On 6/24/16 1:15 PM, Steven Schveighoffer wrote:
The problem that hasn't been made clear is, why can't you just write:
static if(condition)
{
... // some code
return;
}
// some more code
And the answer is, I'm guessing, bug 14835 -- misgui
On 6/24/16 1:15 PM, Steven Schveighoffer wrote:
The problem that hasn't been made clear is, why can't you just write:
static if(condition)
{
... // some code
return;
}
// some more code
And the answer is, I'm guessing, bug 14835 -- misguided "unreachable
statement" warnings.
Should we
On 6/24/16 12:19 PM, Andrei Alexandrescu wrote:
On 06/24/2016 11:47 AM, Mathias Lang wrote:
On Friday, 24 June 2016 at 15:29:18 UTC, Steven Schveighoffer wrote:
On 6/24/16 11:24 AM, Andrei Alexandrescu wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -
On Friday, 24 June 2016 at 17:03:55 UTC, JohnnyC wrote:
On Friday, 24 June 2016 at 15:29:18 UTC, Steven Schveighoffer
wrote:
On 6/24/16 11:24 AM, Andrei Alexandrescu wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
Maybe. That bug report doe
On Friday, 24 June 2016 at 15:29:18 UTC, Steven Schveighoffer
wrote:
On 6/24/16 11:24 AM, Andrei Alexandrescu wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
Maybe. That bug report does not identify any problems. What
happens that's current
On 06/24/2016 11:47 AM, Mathias Lang wrote:
On Friday, 24 June 2016 at 15:29:18 UTC, Steven Schveighoffer wrote:
On 6/24/16 11:24 AM, Andrei Alexandrescu wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
Maybe. That bug report does not identi
On Friday, 24 June 2016 at 15:29:18 UTC, Steven Schveighoffer
wrote:
On 6/24/16 11:24 AM, Andrei Alexandrescu wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
Maybe. That bug report does not identify any problems. What
happens that's current
On Friday, 24 June 2016 at 15:34:42 UTC, Stefan Koch wrote:
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
This would mean treating static if's differently if they alter
control
On Friday, 24 June 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
This would mean treating static if's differently if they alter
control flow in a scope larger then themselves.
Special casing a st
On 6/24/16 11:24 AM, Andrei Alexandrescu wrote:
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
Maybe. That bug report does not identify any problems. What happens
that's currently bad?
-Steve
Does anyone else find this annoying?
https://issues.dlang.org/show_bug.cgi?id=16201 -- Andrei
41 matches
Mail list logo
