On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a Keyword", is now underway. From now until 11:59 PM ET
on May 26 (3:59 AM GMT on May 27), the community has the
opportunity to provide last-minute feedback. If you
On Friday, 26 May 2017 at 01:23:59 UTC, Timon Gehr wrote:
On 25.05.2017 20:57, MysticZach wrote:
struct body {}
interface I {
int foo(int i)
in { assert(i); }
body bar();
}
The ambiguity is fixable by modifying the parser to look ahead
after `body` for `{`. Since virtual interface
On 25.05.2017 20:57, MysticZach wrote:
On Thursday, 25 May 2017 at 11:49:47 UTC, MysticZach wrote:
...there is no known possibility of semantic confusion between the two
potential uses of `body`,
I spoke too soon. I found a place where such semantic ambiguity is
possible. It can only occur
On Thursday, 25 May 2017 at 11:49:47 UTC, MysticZach wrote:
...there is no known possibility of semantic confusion between
the two potential uses of `body`,
I spoke too soon. I found a place where such semantic ambiguity
is possible. It can only occur in interface declarations, and
will not
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a Keyword", is now underway. From now until 11:59 PM ET
on May 26 (3:59 AM GMT on May 27), the community has the
opportunity to provide last-minute feedback. If you
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
I think there are several issues at hand, and they need to be
dealt with individually:
1. `body` is a very useful identifier. It would be nice to have
it available.
2. Contract syntax is too verbose.
3. a. Some people think code
On Thursday, 18 May 2017 at 13:06:38 UTC, Petar Kirov
[ZombineDev] wrote:
On Thursday, 18 May 2017 at 12:56:31 UTC, Meta wrote:
This is pretty much the same as option 2. The short-term
contextual part is covered by Walter's suggestion.
No it's not. What MysticZach suggests, and what I
On Thursday, 18 May 2017 at 12:56:31 UTC, Meta wrote:
On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
I'll add this option to the DIP.
On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
I'll add this option to the DIP.
https://github.com/dlang/DIPs/pull/65
I think (
On Thursday, 18 May 2017 at 03:59:49 UTC, MysticZach wrote:
http://forum.dlang.org/post/kybywnscisxpebezw...@forum.dlang.org ) represents
yet another distinct option. i.e. continue to allow `body`, but make it
optional, that is, you can simply omit it if you want, while also allowing it
as an
On Thursday, 18 May 2017 at 02:13:52 UTC, Meta wrote:
On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
I'll add this option to the DIP.
https://github.com/dlang/DIPs/pull/65
I think (
http://forum.dlang.org/post/kybywnscisxpebezw...@forum.dlang.org
) represents yet another distinct
On Wednesday, 17 May 2017 at 11:46:07 UTC, Meta wrote:
On Tuesday, 16 May 2017 at 18:06:38 UTC, Andrei Alexandrescu
wrote:
On 05/16/2017 01:59 PM, Random D user wrote:
int foo()
in
{
}
out
{
}
do
{
bar();
}
Can't deny I like that. -- Andrei
I'll add this option to the DIP.
On Wed, May 17, 2017 at 05:06:40PM +, MysticZach via Digitalmars-d wrote:
[...]
> 3. If `body` were optional, probably a lot of people wouldn't be using
> it to begin with. I suspect that Jonathan and I are not alone in
> thinking that it's not just useless, it's annoying. Thus, only code
>
On Wednesday, 17 May 2017 at 09:57:41 UTC, Basile B. wrote:
On Wednesday, 17 May 2017 at 09:53:49 UTC, MysticZach wrote:
Option 4) Keep `body`, but make it both contextual *and*
optional. It becomes usable as an identifier, and those who
think it's unnecessary are appeased. The downside is
On 17.05.2017 18:23, Timon Gehr wrote:
On 17.05.2017 14:47, Patrick Schluter wrote:
I don't understand why this would be uglier than )( used in templates.
.
This is a different case. In C-like languages '(' is essentially a
binary operator ...
Or rather, a postfix operator.
On 17.05.2017 14:47, Patrick Schluter wrote:
I don't understand why this would be uglier than )( used in templates.
.
This is a different case. In C-like languages '(' is essentially a
binary operator and the second set of parens applies to the result of
the first set. f(a)(b) is curried
On 5/16/2017 12:48 PM, Timon Gehr wrote:
It's a good option to have, but D is not an expression-based language, so this
can be painful, as you cannot declare intermediate variables nor use statements.
You can by using lambdas, but embedded lambdas are rather awkward.
On 5/17/17 8:47 AM, Patrick Schluter wrote:
On Tuesday, 16 May 2017 at 19:25:25 UTC, Steven Schveighoffer wrote:
1) Consistency with functions without contracts.
This only applies to the "naked" version which has ugly }{ in it. The
other options people are asking about are replacing body
On Tuesday, 16 May 2017 at 19:25:25 UTC, Steven Schveighoffer
wrote:
1) Consistency with functions without contracts.
This only applies to the "naked" version which has ugly }{ in
it. The other options people are asking about are replacing
body with a keyword, which I think you agree would
On Tuesday, 16 May 2017 at 18:06:38 UTC, Andrei Alexandrescu
wrote:
On 05/16/2017 01:59 PM, Random D user wrote:
int foo()
in
{
}
out
{
}
do
{
bar();
}
Can't deny I like that. -- Andrei
I'll add this option to the DIP.
On Wednesday, 17 May 2017 at 09:53:49 UTC, MysticZach wrote:
On Wednesday, 17 May 2017 at 08:03:13 UTC, Mike Parker wrote:
* Is it a good idea to remove body's status as a reserved
keyword?
* If so, which option is best?
1) Make it contextual
2) Replace it with another keyword (`function`
On Wednesday, 17 May 2017 at 08:03:13 UTC, Mike Parker wrote:
* Is it a good idea to remove body's status as a reserved
keyword?
* If so, which option is best?
1) Make it contextual
2) Replace it with another keyword (`function` was suggested
in the DIP, `do` in this thread).
3) A
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
I think there are several issues at hand, and they need to be
dealt with individually:
1. `body` is a very useful identifier. It would be nice to have
it available.
2. Contract syntax is too verbose.
3. a. Some people think
On Wednesday, May 17, 2017 01:01:29 MysticZach via Digitalmars-d wrote:
> I think there are several issues at hand, and they need to be
> dealt with individually:
>
> 1. `body` is a very useful identifier. It would be nice to have
> it available.
>
> 2. Contract syntax is too verbose.
>
> 3. a.
On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
I think the thread will be more productive if the posters
commit to answering just one of these issues
Agreed. Let's hope it's the topic that the DIP is actually
addressing ;-)
On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
To me, it's actually worse, because now you have a visual
conflation with do-loops.
Overall, what I don't like about contract syntax is that it is
so unbearably verbose. It's not just the in and out blocks and
the (IMO redundant)
On Tuesday, 16 May 2017 at 21:39:19 UTC, jmh530 wrote:
I agree with your points, but it doesn't necessarily preclude
adding in/out statements. My only qualm is that they would seem
very similar to scope statements. Perhaps scope(in) and
scope(out(x)) or something like that. Would not break
On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:
int fun(int a) {
in assert(...);
out(x) assert(...);
// do stuff
}
It's nice, i like it but it cant work as simply. You're
forgetting that interface member functions can have contracts.
With this syntax interfaces member
On 5/16/17 3:43 PM, Timon Gehr wrote:
On 16.05.2017 21:25, Steven Schveighoffer wrote:
I'm specifically asking if just removing the 'keyword-ness' of it is not
doable for some reason.
It's easy to do technically. (The bad thing about option 1 is that it's
the kind of thing that would probably
On 16.05.2017 22:00, H. S. Teoh via Digitalmars-d wrote:
On Tue, May 16, 2017 at 09:48:07PM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
I'm saying no to this:
...
{
}{
}
It doesn't have to be formatted that way. For example:
int foo()
in { assert(blah); }
{
On Tue, May 16, 2017 at 09:48:07PM +0200, Timon Gehr via Digitalmars-d wrote:
[...]
> I'm saying no to this:
>
> ...
> {
>
> }{
>
> }
It doesn't have to be formatted that way. For example:
int foo()
in { assert(blah); }
{
// not so bad after all
On 16.05.2017 20:57, H. S. Teoh via Digitalmars-d wrote:
On Tue, May 16, 2017 at 08:43:01PM +0200, Timon Gehr via Digitalmars-d wrote:
On 16.05.2017 20:06, Andrei Alexandrescu wrote:
On 05/16/2017 01:59 PM, Random D user wrote:
int foo()
in
{
}
out
{
}
do
{
bar();
}
Can't deny I like
On 16.05.2017 21:25, Steven Schveighoffer wrote:
I'm specifically asking if just removing the 'keyword-ness' of it is not
doable for some reason.
It's easy to do technically. (The bad thing about option 1 is that it's
the kind of thing that would probably not arise from an up-front
language
On Tuesday, 16 May 2017 at 19:25:25 UTC, Steven Schveighoffer
wrote:
On 5/16/17 2:48 PM, Eugene Wissner wrote:
On Tuesday, 16 May 2017 at 18:34:06 UTC, Steven Schveighoffer
wrote:
1) Consistency with functions without contracts.
This only applies to the "naked" version which has ugly }{ in
On Tuesday, 16 May 2017 at 19:24:43 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 16 May 2017 at 19:23:28 UTC, Eugene Wissner wrote:
What about error messages. With asserts I get the line where
the assert failed. Can I get an information which condition
failed (sorry for the question, I don't
On 5/16/17 2:48 PM, Eugene Wissner wrote:
On Tuesday, 16 May 2017 at 18:34:06 UTC, Steven Schveighoffer wrote:
On 5/12/17 12:17 PM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59
On Tuesday, 16 May 2017 at 19:23:28 UTC, Eugene Wissner wrote:
What about error messages. With asserts I get the line where
the assert failed. Can I get an information which condition
failed (sorry for the question, I don't know how it works in
other languages)?
Use multiple requires/ensures
On Tuesday, 16 May 2017 at 19:18:43 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
this ugly verbosity, but imagine how much better it would be
if we could write something like this instead:
int foo(T, U)(T t, U u)
if
On Tuesday, 16 May 2017 at 18:57:37 UTC, H. S. Teoh wrote:
this ugly verbosity, but imagine how much better it would be if
we could write something like this instead:
int foo(T, U)(T t, U u)
if (sigConstraints!T && sigConstraints!U)
in (t > 0 && u < 10)
out(foo
On Tue, May 16, 2017 at 08:43:01PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 16.05.2017 20:06, Andrei Alexandrescu wrote:
> > On 05/16/2017 01:59 PM, Random D user wrote:
> > >
> > > int foo()
> > > in
> > > {
> > > }
> > > out
> > > {
> > > }
> > > do
> > > {
> > > bar();
> > > }
> >
>
On Tuesday, 16 May 2017 at 16:10:56 UTC, David Gileadi wrote:
One possible substitute for the `function` keyword in option 2
could be `do`. I'm not convinced it's a good substitute, but I
thought I'd throw it out there.
Looks weird for a C-style language imho.
On Tuesday, 16 May 2017 at 18:34:06 UTC, Steven Schveighoffer
wrote:
On 5/12/17 12:17 PM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a
Keyword", is now underway. From now until 11:59 PM ET on May
26 (3:59 AM
GMT on May 27), the community has the
On 16.05.2017 20:06, Andrei Alexandrescu wrote:
On 05/16/2017 01:59 PM, Random D user wrote:
int foo()
in
{
}
out
{
}
do
{
bar();
}
Can't deny I like that. -- Andrei
Beats options 2 and 3.
On 16.05.2017 19:44, MysticZach wrote:
On Tuesday, 16 May 2017 at 17:42:11 UTC, MysticZach wrote:
On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:
auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
}
Are you really arguing for this?
I don't want to write code
On 5/12/17 12:17 PM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
GMT on May 27), the community has the opportunity to provide last-minute
feedback. If you missed the
On 05/16/2017 01:59 PM, Random D user wrote:
int foo()
in
{
}
out
{
}
do
{
bar();
}
Can't deny I like that. -- Andrei
On Sunday, 14 May 2017 at 15:39:12 UTC, Walter Bright wrote:
On 5/12/2017 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a
Keyword", is now underway.
A combination of Options 1 and 2:
1. Introduce 'function' as an alternative to 'body'.
On Tuesday, 16 May 2017 at 17:42:11 UTC, MysticZach wrote:
On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:
auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
}
Are you really arguing for this?
I don't want to write code like this.
It's not any better than
On Tuesday, 16 May 2017 at 15:22:12 UTC, Timon Gehr wrote:
auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
}
Are you really arguing for this?
I don't want to write code like this.
It's not any better than this:
auto foo()in{
assert(true);
}out{
assert(true);
On 16.05.2017 17:47, Jonathan M Davis via Digitalmars-d wrote:
...
And having to
have body (or function whatever other keyword we might put there) just makes
contracts that much more verbose
That's seriously exaggerated.
- as well as being inconsistent with how
functions bodies are declared
On 5/12/17 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
GMT on May 27), the community has the opportunity to provide last-minute
feedback. If you missed the
On Tuesday, May 16, 2017 17:22:12 Timon Gehr via Digitalmars-d wrote:
> On 15.05.2017 03:18, Jonathan M Davis via Digitalmars-d wrote:
> > So, while I do like the idea of getting the word body back as an
> > identifier, what really appeals to me here is getting rid of the need
> > for it with
On 15.05.2017 03:18, Jonathan M Davis via Digitalmars-d wrote:
So, while I do like the idea of getting the word body back as an identifier,
what really appeals to me here is getting rid of the need for it with
contracts.
auto foo()in{
assert(true);
}out{
assert(true);
}{
return 3;
On Tuesday, 16 May 2017 at 13:50:59 UTC, Jonathan M Davis wrote:
All I'm arguing for is that if we're removing body as a
keyword, there's no need to replace it with function or any
other word in contracts. We can simply deprecate its use as a
keyword and not replace it, letting it then be used
On Tuesday, May 16, 2017 12:50:37 Meta via Digitalmars-d wrote:
> On Tuesday, 16 May 2017 at 10:28:09 UTC, Kagamin wrote:
> > On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
> >> So, while I do like the idea of getting the word body back as
> >> an identifier, what really appeals
On Tuesday, 16 May 2017 at 10:28:09 UTC, Kagamin wrote:
On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
So, while I do like the idea of getting the word body back as
an identifier, what really appeals to me here is getting rid
of the need for it with contracts. And using
On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
So, while I do like the idea of getting the word body back as
an identifier, what really appeals to me here is getting rid of
the need for it with contracts. And using function instead of
body doesn't help that at all.
The
On 16.05.2017 05:44, MysticZach wrote:
...
With your proposal, this syntax would already be taken for a function
with an empty implementation.
Also, does a final function with contracts, but no body, make any sense?
What's the use case?
...
di files.
Even if there were some use case
On Tuesday, 16 May 2017 at 03:44:54 UTC, MysticZach wrote:
It seems to me that the compiler could detect a presence or
lack of a body simply by the presence or absence of any
statement after the contracts, i.e.,
interface D {
// fun is implicitly overridable here
int fun() {
in
On Monday, 15 May 2017 at 02:02:42 UTC, Basile B. wrote:
On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
Not that a whole new way of doing things is called for... but
I think a better design would have been to allow 'in' and
'out' statements in the function itself, with no need for
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
...
3. deprecate, remove, forget.
During the deprecation period, it could live as "contextual
keyword", or actually with grammar modified to expect an
identifier "body" instead of keyword. That would allow using
"body" as
On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
Not that a whole new way of doing things is called for... but I
think a better design would have been to allow 'in' and 'out'
statements in the function itself, with no need for brackets if
you only have one line's worth of contract,
On Monday, 15 May 2017 at 01:39:34 UTC, MysticZach wrote:
Not that a whole new way of doing things is called for... but I
think a better design would have been to allow 'in' and 'out'
statements in the function itself, with no need for brackets if
you only have one line's worth of contract,
On Monday, 15 May 2017 at 01:18:02 UTC, Jonathan M Davis wrote:
Why would we want to introduce function as an alternative to
body? Personally, I've always found the need to use body to be
very odd and annoying. It doesn't need to be there when you
don't have in or out contracts, and it just
On Sunday, May 14, 2017 08:39:12 Walter Bright via Digitalmars-d wrote:
> On 5/12/2017 9:17 AM, Mike Parker wrote:
> > The first stage of the formal review for DIP 1003 [1], "Remove body as a
> > Keyword", is now underway.
>
> A combination of Options 1 and 2:
>
> 1. Introduce 'function' as an
On 14.05.2017 17:39, Walter Bright wrote:
On 5/12/2017 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway.
A combination of Options 1 and 2:
1. Introduce 'function' as an alternative to 'body'.
2. Turn 'body' into a
On 14.05.2017 18:36, Kagamin wrote:
On Friday, 12 May 2017 at 18:03:43 UTC, H. S. Teoh wrote:
I disagree that `function` is not overloaded: it *will* be overloaded
if option 2 is chosen, because `function` currently means function
*pointer*, not the function body itself. For this reason, I
On Sunday, 14 May 2017 at 16:35:32 UTC, Kagamin wrote:
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
[1]
https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
Currently function declarations with contracts don't require
semicolon at the end.
On Friday, 12 May 2017 at 18:03:43 UTC, H. S. Teoh wrote:
I disagree that `function` is not overloaded: it *will* be
overloaded if option 2 is chosen, because `function` currently
means function *pointer*, not the function body itself. For
this reason, I oppose Option 2.
Function literal
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
[1]
https://github.com/dlang/DIPs/blob/fbb797f61ac92300eda1d63202157cd2a30ba555/DIPs/DIP1003.md
Currently function declarations with contracts don't require
semicolon at the end. This conflicts with options 1 and 3 and is
not
On 5/12/2017 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway.
A combination of Options 1 and 2:
1. Introduce 'function' as an alternative to 'body'.
2. Turn 'body' into a contextual keyword.
3. Deprecate 'body' as
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
[1] Also, here is a list of existing contextual keywords:
exit
success
failure
C
C++
D
Windows
Pascal
System
Objective-C
They are not used alone. They are used in a **statement** and
surrounded by parens.
It's important because
On 5/14/17 9:53 AM, Petar Kirov [ZombineDev] wrote:
Edit: I may be wrong. Here's a case that's on the edge of ambiguity:
void main()
{
void inner(int x)
in { }
{
writeln("WAT");
}
}
If 'body' was optional, what would be the output of the program? It
turns out
that the
On Sunday, 14 May 2017 at 13:55:44 UTC, Steven Schveighoffer
wrote:
On 5/14/17 9:24 AM, Petar Kirov [ZombineDev] wrote:
By making body optional and a contextual keyword there should
be no
breaking changes (except for obscure code like `static assert
(!__traits(compiles, { mixin ("int
On 5/14/17 9:24 AM, Petar Kirov [ZombineDev] wrote:
By making body optional and a contextual keyword there should be no
breaking changes (except for obscure code like `static assert
(!__traits(compiles, { mixin ("int body;"); }))` :D).
It doesn't even need to be optional. It can be required
On Sunday, 14 May 2017 at 01:30:19 UTC, Timon Gehr wrote:
On 14.05.2017 00:07, Petar Kirov [ZombineDev] wrote:
How would you feel about:
if(condition){ then(); }
{ otherwise(); }
I don't see any problem, ...
The intention is that in this _hypothetical_ (hence "would")
grammar (which is
On Sunday, 14 May 2017 at 13:04:12 UTC, Steven Schveighoffer
wrote:
On 5/13/17 6:07 PM, Petar Kirov [ZombineDev] wrote:
On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
On 5/13/17 6:07 PM, Petar Kirov [ZombineDev] wrote:
On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
On 12.05.2017 18:17, Mike Parker wrote:
The first stage of the
On Saturday, 13 May 2017 at 10:46:51 UTC, Jonathan M Davis wrote:
be DOA. And not having them definitely simplifies lexing and
parsing D code, so it's quite understandable that Walter is
against them.
I don't see how it complicates the lexer? "body" would be a valid
identifier, so it would
On 14.05.2017 00:07, Petar Kirov [ZombineDev] wrote:
How would you feel about:
if(condition){ then(); }
{ otherwise(); }
I don't see any problem, ...
The intention is that in this _hypothetical_ (hence "would") grammar
(which is somewhat analogous to what is proposed in 3), the second
On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
On 12.05.2017 18:17, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1],
"Remove body as a
On 13.05.2017 20:26, Eugene Wissner wrote:
On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
On 12.05.2017 18:17, Mike Parker wrote:
The first stage of the formal review
On Saturday, 13 May 2017 at 18:07:57 UTC, Timon Gehr wrote:
On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
On 12.05.2017 18:17, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1],
"Remove body as a
On 13.05.2017 16:30, Petar Kirov [ZombineDev] wrote:
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
On 12.05.2017 18:17, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway. From now until 11:59 PM ET on May 26
On Saturday, 13 May 2017 at 10:27:25 UTC, Timon Gehr wrote:
On 12.05.2017 18:17, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a
Keyword", is now underway. From now until 11:59 PM ET on May
26 (3:59 AM
GMT on May 27), the community has the
On Saturday, 13 May 2017 at 13:16:40 UTC, Walter Bright wrote:
On 5/12/2017 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a
Keyword", is now underway.
I'd like to congratulate Jared Hanson for a particularly
well-written DIP which sets a
On 5/12/2017 9:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway.
I'd like to congratulate Jared Hanson for a particularly well-written DIP which
sets a high standard for how things ought to be done. Well done!
On Saturday, 13 May 2017 at 10:46:51 UTC, Jonathan M Davis wrote:
On Saturday, May 13, 2017 08:50:10 via Digitalmars-d wrote:
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
> The first stage of the formal review for DIP 1003 [1],
> "Remove body as a Keyword", is now underway. From
On Fri, 12 May 2017 16:17:03 +, Mike Parker wrote:
> The first stage of the formal review for DIP 1003 [1], "Remove body as a
> Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
> GMT on May 27), the community has the opportunity to provide last-minute
> feedback. If
On Saturday, May 13, 2017 08:50:10 via Digitalmars-d wrote:
> On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
> > The first stage of the formal review for DIP 1003 [1], "Remove
> > body as a Keyword", is now underway. From now until 11:59 PM ET
> > on May 26 (3:59 AM GMT on May 27), the
On 12.05.2017 18:17, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
GMT on May 27), the community has the opportunity to provide last-minute
feedback. If you missed the
On Saturday, 13 May 2017 at 08:50:10 UTC, Petar Kirov
[ZombineDev] wrote:
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a Keyword", is now underway. From now until 11:59 PM
ET on May 26 (3:59 AM GMT on May 27),
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a Keyword", is now underway. From now until 11:59 PM ET
on May 26 (3:59 AM GMT on May 27), the community has the
opportunity to provide last-minute feedback. If you
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a Keyword", is now underway. From now until 11:59 PM ET
on May 26 (3:59 AM GMT on May 27), the community has the
opportunity to provide last-minute feedback. If you
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a Keyword", is now underway. From now until 11:59 PM ET
on May 26 (3:59 AM GMT on May 27), the community has the
opportunity to provide last-minute feedback. If you
On 5/12/17 12:17 PM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
GMT on May 27), the community has the opportunity to provide last-minute
feedback. If you missed the
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove
body as a Keyword", is now underway. From now until 11:59 PM ET
on May 26 (3:59 AM GMT on May 27), the community has the
opportunity to provide last-minute feedback. If you
On 05/12/2017 09:17 AM, Mike Parker wrote:
The first stage of the formal review for DIP 1003 [1], "Remove body as a
Keyword", is now underway. From now until 11:59 PM ET on May 26 (3:59 AM
GMT on May 27), the community has the opportunity to provide last-minute
feedback. If you missed the
On Fri, May 12, 2017 at 04:17:03PM +, Mike Parker via Digitalmars-d wrote:
> The first stage of the formal review for DIP 1003 [1], "Remove body as
> a Keyword", is now underway. From now until 11:59 PM ET on May 26
> (3:59 AM GMT on May 27), the community has the opportunity to provide
>
The feedback period for the formal review of DIP 1003 has begun.
Please provide all feedback in the review thread:
http://forum.dlang.org/post/wcqebjzdjxldeywlx...@forum.dlang.org
Also, keep in mind that the first preliminary review of DIP 1005
ends in less than 24 hours.
1 - 100 of 101 matches
Mail list logo
