On Friday, 25 January 2019 at 07:02:47 UTC, Walter Bright wrote:
On 1/24/2019 4:21 PM, Elie Morisse wrote:
I didn't see that coming and I'm deeply frustrated and
disappointed by this review and rejection.
On the contrary. It is good to find conceptual errors before
implementing it.
You
No, it is not rejected in principle. Finding serious errors in it on the eve of
approval is disappointing, and is not auspicious for being in a hurry to approve it.
For example, I spent a lot of time working on ARC, and was all set to move
forward with it when Timon stepped in and showed it
On 1/24/2019 12:01 PM, kinke wrote:
`out` params are default-initialized on entry.
Ignoring backwards compatibility for a second, I think getting rid of that would
actually be beneficial (most args are probably already default-initialized by
the callee in the line above the call...)
The
On 1/24/2019 4:21 PM, Elie Morisse wrote:
I didn't see that coming and I'm deeply frustrated and disappointed by this
review and rejection.
On the contrary. It is good to find conceptual errors before implementing it.
They're a LOT cheaper to fix earlier rather than when it is in the field.
On Friday, 25 January 2019 at 00:31:50 UTC, 12345swordy wrote:
On Thursday, 24 January 2019 at 23:43:21 UTC, Walter Bright
wrote:
It's no problem if you want to rework the existing text, just
submit it as a new DIP.
And wait for another 180+ days for a fix? Come on dude, can you
understand
On Thu, Jan 24, 2019 at 6:35 PM Walter Bright via
Digitalmars-d-announce wrote:
>
> On 1/24/2019 4:31 PM, 12345swordy wrote:
> > And wait for another 180+ days for a fix? Come on dude, can you understand
> > the
> > frustration being display here?
>
> Of course it's frustrating. On the other
On Thu, Jan 24, 2019 at 6:35 PM Walter Bright via
Digitalmars-d-announce wrote:
>
> On 1/24/2019 4:31 PM, 12345swordy wrote:
> > And wait for another 180+ days for a fix? Come on dude, can you understand
> > the
> > frustration being display here?
>
> Of course it's frustrating. On the other
On 1/24/2019 4:31 PM, 12345swordy wrote:
And wait for another 180+ days for a fix? Come on dude, can you understand the
frustration being display here?
Of course it's frustrating. On the other hand, we've had a lot of problems
stemming from implementing features without thoroughly
On Thursday, 24 January 2019 at 23:43:21 UTC, Walter Bright wrote:
It's no problem if you want to rework the existing text, just
submit it as a new DIP.
And wait for another 180+ days for a fix? Come on dude, can you
understand the frustration being display here?
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md
Here, the DIP Author clearly expresses two reasons why a
programmer may choose to declare a function to accept ref
arguments. The Language Maintainers see this
On Thursday, 24 January 2019 at 23:59:30 UTC, Walter Bright wrote:
On 1/24/2019 1:03 PM, kinke wrote:
(bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy =
b();)) , __gate = true , f(__pfx, __pfy);
There must be an individual gate for each of __pfx and pfy.
With the rewrite above, if b()
On 1/24/2019 1:03 PM, kinke wrote:
(bool __gate = false;) , ((A __pfx = a();)) , ((B __pfy = b();)) , __gate = true
, f(__pfx, __pfy);
There must be an individual gate for each of __pfx and pfy. With the rewrite
above, if b() throws then _pfx won't be destructed.
(All this rigamarole is
On Thu, Jan 24, 2019 at 3:50 PM Rubn via Digitalmars-d-announce
wrote:
>
> On Thursday, 24 January 2019 at 23:18:11 UTC, kinke wrote:
> > Proposed `out` semantics:
> > ---
> > void increment(out long value) { ++value; }
> > increment(out value);
> > ---
> >
> > vs. pointer version with current
On Thu, Jan 24, 2019 at 3:45 PM Walter Bright via
Digitalmars-d-announce wrote:
>
> On 1/24/2019 1:31 AM, Manu wrote:
> > This process is pretty unsatisfying, because it ships off to a
> > black-box committee, who were apparently able to misunderstand the
> > substance of the proposal and then
On Thursday, 24 January 2019 at 23:18:11 UTC, kinke wrote:
Proposed `out` semantics:
---
void increment(out long value) { ++value; }
increment(out value);
---
vs. pointer version with current `out` semantics:
---
void increment(long* pValue) { ++(*pValue); }
increment();
---
The pointer
On Thursday, 24 January 2019 at 22:38:01 UTC, Manu wrote:
Shared in/out functions are very rare by contrast to out
parameters.
The code I write is the exact opposite of your perception - some
occasional side-effect-mutations of params, and almost no stuff
'returned' as out params.
What are
On Thursday, 24 January 2019 at 14:44:07 UTC, bachmeier wrote:
Of course, one could argue that it must have offered enough to
keep some of them interested. They were able to get stuff done
when they used it.
The build in and good performing http server hit the sweet spot.
Never underestimate
On Thursday, 24 January 2019 at 21:03:29 UTC, kinke wrote:
Describing this stuff in detail (rewritten expression?!), isn't
trivial and requires knowledge about how calls and
construction/destruction of argument expressions works.
E.g., the f() call in the code above is lowered to (-vcg-ast):
On Thu, Jan 24, 2019 at 1:05 PM kinke via Digitalmars-d-announce
wrote:
>
> On Thursday, 24 January 2019 at 09:04:41 UTC, Nicholas Wilson
> wrote:
> > On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> >> The second problem is the use of := (which the DIP Author
> >> defines as
On Thu, Jan 24, 2019 at 12:05 PM kinke via Digitalmars-d-announce
wrote:
>
> On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:
> > We discussed and concluded that one mechanism to mitigate this
> > issue
> > was already readily available, and it's just that 'out' gains a
> > much
> >
On Thursday, 24 January 2019 at 21:57:57 UTC, Rubn wrote:
it could be an error if the function didn't assign the variable
a value instead
I don't like that, conditional mutations like this should work
too:
void conditionalIncrement(bool condition, out long value) {
if (condition)
On Thursday, 24 January 2019 at 20:01:45 UTC, kinke wrote:
On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:
We discussed and concluded that one mechanism to mitigate this
issue
was already readily available, and it's just that 'out' gains
a much
greater sense of identity (which is
On Thursday, 24 January 2019 at 09:24:19 UTC, Nicholas Wilson
wrote:
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
Walter and Andrei have declined to accept DIP 1016, "ref T
accepts r-values", on the grounds that it has two fundamental
flaws that would open holes in the
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
fun(10)
==>
{
T __temp0 = void;
fun(__temp0 := 10);
}
The first problem the Language Maintainers identified with this
approach is that the rewrite is from an expression to a
statement, rendering it invalid.
The expression
On Thursday, 17 January 2019 at 04:19:27 UTC, Brian wrote:
Google gRPC is A high performance, open-source universal RPC
framework.
[...]
Cool. Thanks for contributing. I look forward to using it in a
future project with microservices.
On Thursday, 24 January 2019 at 09:04:41 UTC, Nicholas Wilson
wrote:
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
The second problem is the use of := (which the DIP Author
defines as representing "the initial construction, and not a
copy operation as would be expected if
On Thursday, 24 January 2019 at 20:01:45 UTC, kinke wrote:
(most args are probably already default-initialized by the
callee in the line above the call...)
Should be 'by the callER' of course.
On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:
We discussed and concluded that one mechanism to mitigate this
issue
was already readily available, and it's just that 'out' gains a
much
greater sense of identity (which is actually a positive
side-effect if
you ask me!).
You have a
On Thursday, 24 January 2019 at 13:58:59 UTC, Mike Parker wrote:
I said in my annual D Blog retrospective that I wanted to do a
similar post focused on D at large. Sebastian Wilzbach sent me
a tremendously helpful info dump of all sorts of goings on,
most of which I knew nothing about. When I
On Wednesday, 23 January 2019 at 18:42:06 UTC, bauss wrote:
Go is garbage and it's only popular because Google is behind it.
It has absolutely nothing to do with the language itself.
I don't know if I'd agree that it's garbage - it has a lot of
appeal to certain types of programmers, though
I said in my annual D Blog retrospective that I wanted to do a
similar post focused on D at large. Sebastian Wilzbach sent me a
tremendously helpful info dump of all sorts of goings on, most of
which I knew nothing about. When I sat down to write the post, it
occurred to me that since Adam
On Thursday, 24 January 2019 at 09:49:14 UTC, Manu wrote:
On Thu, Jan 24, 2019 at 1:25 AM Nicholas Wilson via We
discussed and concluded that one mechanism to mitigate this
issue
was already readily available, and it's just that 'out' gains a
much
greater sense of identity (which is actually a
On Thu, Jan 24, 2019 at 1:25 AM Nicholas Wilson via
Digitalmars-d-announce wrote:
>
> On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
> > Walter and Andrei have declined to accept DIP 1016, "ref T
> > accepts r-values", on the grounds that it has two fundamental
> > flaws that
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
Walter and Andrei have declined to accept DIP 1016, "ref T
accepts r-values", on the grounds that it has two fundamental
flaws that would open holes in the language. They are not
opposed to the feature in principle and suggested
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
Walter and Andrei have declined to accept DIP 1016, "ref T
accepts r-values", on the grounds that it has two fundamental
flaws that would open holes in the language. They are not
opposed to the feature in principle and suggested
On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:
Walter and Andrei have declined to accept DIP 1016, "ref T
accepts r-values", on the grounds that it has two fundamental
flaws that would open holes in the language. They are not
opposed to the feature in principle and suggested
36 matches
Mail list logo
