Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual code doing something
}
in your API you didn't document that this will change `a` (or we
will assume the user simply didn't read because you would never
do something like this).
The
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual code doing something
}
in your API you didn't document that this will change `a` (or
we will assume the user simply didn't
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual code doing something
}
in your API you didn't document that this will change `a` (or
we will assume the user simply didn't
Meta wrote:
If a parameter is marked as ref then you have to assume it will be
modified by the function (unless it's const/inout/immutable). If it's
marked as out then you know it will be. If you didn't know that the
function takes its parameters by ref or out... You're should've RTFM.
now i
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual code doing something
}
[...]
Syntax wise we could force you to say foo(&something).
Which fits perfectly in the existing p
On Sunday, 28 May 2017 at 22:03:48 UTC, Stefan Koch wrote:
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual code doing something
}
[...]
Syntax wise we could force you to
On Sunday, 28 May 2017 at 22:18:01 UTC, Stanislav Blinov wrote:
On Sunday, 28 May 2017 at 22:03:48 UTC, Stefan Koch wrote:
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual
Stefan Koch wrote:
Personally I stay away from ref precisely because of it's silent caller
syntax.
same here. i prefer to use pointers instead, 'cause they are visible at the
calling site.
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual code doing something
}
[...]
It seems nice in theory but how will it interact with generic
code?
Perhaps it should be op
On Sunday, May 28, 2017 17:54:30 WebFreak001 via Digitalmars-d wrote:
> I think the user should be enforced to use foo(ref input) instead
> of foo(input) as it greatly increases understanding of the code
> on the caller side and another advantage is that programs
> analyzing the AST can better unde
On Sunday, 28 May 2017 at 19:10:49 UTC, ketmar wrote:
Meta wrote:
If a parameter is marked as ref then you have to assume it
will be modified by the function (unless it's
const/inout/immutable). If it's marked as out then you know it
will be. If you didn't know that the function takes its
pa
That's what C# does. I always liked that a lot, and even argued in favor
of doing the same in D (ages ago). It got shot down way back when, so
unfortunately, I don't think any reversal is going to happen.
Getting in the way of UFCS and generic code are fair points, although
they don't stike me
On 05/28/2017 03:06 PM, Meta wrote:
If you didn't know that the
function takes its parameters by ref or out... You're should've RTFM.
That's the same reasoning that's been used to excuse just about every
API blunder in C's infamously unsafe bug-riddled history.
On Monday, 29 May 2017 at 01:56:19 UTC, Nick Sabalausky
(Abscissa) wrote:
On 05/28/2017 03:06 PM, Meta wrote:
If you didn't know that the function takes its parameters by
ref or out... You're should've RTFM.
That's the same reasoning that's been used to excuse just about
every API blunder i
On 05/29/2017 12:57 AM, Ola Fosheim Grostad wrote:
On Monday, 29 May 2017 at 01:56:19 UTC, Nick Sabalausky (Abscissa) wrote:
On 05/28/2017 03:06 PM, Meta wrote:
If you didn't know that the function takes its parameters by ref or
out... You're should've RTFM.
That's the same reasoning that's
On Monday, 29 May 2017 at 05:39:41 UTC, Nick Sabalausky
(Abscissa) wrote:
Did you intend that as a response to my post or to the OP?
Sounds more like it was directed at the OP.
I tried to reply to:
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Should the language spec say that those functions should get
called with `foo(ref input);` so that surprises like this where
the user doesn't check the docs/implementation can't happen
(like in C#)?
I think it's mostly about good tast
On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote:
But what would be worth a consideration, is that perhaps one
should be allowed to pass rvalues as reference with something
like this? According to TDPL, ref arguments do not take rvalues
to prevent bugs where you accidently copy something bef
On Monday, May 29, 2017 07:39:40 Dukc via Digitalmars-d wrote:
> But what would be worth a consideration, is that perhaps one
> should be allowed to pass rvalues as reference with something
> like this? According to TDPL, ref arguments do not take rvalues
> to prevent bugs where you accidently copy
Meta wrote:
On Sunday, 28 May 2017 at 19:10:49 UTC, ketmar wrote:
Meta wrote:
If a parameter is marked as ref then you have to assume it will be
modified by the function (unless it's const/inout/immutable). If it's
marked as out then you know it will be. If you didn't know that the
function
On Monday, 29 May 2017 at 07:51:13 UTC, Jonathan M Davis wrote:
I expect that we're going to see a DIP related to rvalue
references at some point here, because some of the folks
(particularly the game folks) think that it's critical to be
able to have a function that doesn't care whether it's t
Ola Fosheim Grostad wrote:
This is information that a good IDE could be designed to provide.
when people start talking about how IDE can help to solve particular
language problem, it is a clear sign of bad language design.
Nicholas Wilson wrote:
On Sunday, 28 May 2017 at 17:54:30 UTC, WebFreak001 wrote:
Imagine you wrote a function
void foo(ref int a) {
if (std.random.uniform(0, 10) == 0)
a = 0;
// Actual code doing something
}
[...]
It seems nice in theory but how will it interact with generic code?
On Monday, May 29, 2017 08:22:23 Ola Fosheim Grøstad via Digitalmars-d
wrote:
> On Monday, 29 May 2017 at 07:51:13 UTC, Jonathan M Davis wrote:
> > I expect that we're going to see a DIP related to rvalue
> > references at some point here, because some of the folks
> > (particularly the game folks
Nick Sabalausky (Abscissa) wrote:
In response to any claim that this isn't a real problem in practice, I
submit the possibility that, if it indeed isn't a real problem, maybe
that's *because* of people (like Stefan and ketmar) simply avoiding the
feature entirely so that it *doesn't* become a
On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote:
With C++, if you have const T&, it will accept both lvalues and
rvalues. A number of folks (particularly those writing games)
want an equivalent to that in D where they can then pass both
lvalues and rvalues without incurring a cop
On Monday, May 29, 2017 09:17:31 Ola Fosheim Grøstad via Digitalmars-d
wrote:
> On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote:
> > With C++, if you have const T&, it will accept both lvalues and
> > rvalues. A number of folks (particularly those writing games)
> > want an equivale
On Monday, 29 May 2017 at 08:40:27 UTC, ketmar wrote:
yet i must say that using pointers in a code where they should
be references makes me... nervous. it just doesn't feel right.
but meh, i'll trade that (and safety, 'cause `&` is unsafe) for
"call site ref indicator".
So one win with dip100
On Monday, 29 May 2017 at 07:46:07 UTC, Stanislav Blinov wrote:
On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote:
[snip]
Explicitly? It is:
import std.stdio;
struct S
{
int v;
}
void foo(ref S s)
{
writeln("took S by ref: ", s.v);
}
void foo(S s)
{
writeln("took rvalue S..."
On Monday, 29 May 2017 at 07:39:40 UTC, Dukc wrote:
I think it's mostly about good taste on what you define
functions to take as ref input. I have a feeling the present
way is not a big problem in practice because it is intuitive
somehow. Besides, member functions mutate their class/struct
any
On Monday, 29 May 2017 at 15:31:26 UTC, WebFreak001 wrote:
well for the extension functions I wrote that if the ref
parameter is the first argument and it's called with ufcs
syntax, it could implicitly add the ref probably. I don't think
there are any big issues with that, it does look like a m
On Monday, 29 May 2017 at 08:41:05 UTC, Jonathan M Davis wrote:
I probably didn't say it very well.
With C++, if you have const T&, it will accept both lvalues and
rvalues. A number of folks (particularly those writing games)
want an equivalent to that in D where they can then pass both
lval
On Monday, May 29, 2017 17:19:27 Stanislav Blinov via Digitalmars-d wrote:
> `in` is `const scope`
Walter recently changed is that in is now just const, because scope was not
properly implemented previously, and folks were using in all over the place,
so the odds of code breaking when scope was pr
On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
On Monday, May 29, 2017 17:19:27 Stanislav Blinov via
Digitalmars-d wrote:
`in` is `const scope`
Walter recently changed is that in is now just const, because
scope was not properly implemented previously, and folks were
using i
On Monday, May 29, 2017 20:00:12 Stanislav Blinov via Digitalmars-d wrote:
> On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
> > On Monday, May 29, 2017 17:19:27 Stanislav Blinov via
> >
> > Digitalmars-d wrote:
> >> `in` is `const scope`
> >
> > Walter recently changed is that in i
On Monday, 29 May 2017 at 20:31:18 UTC, Jonathan M Davis wrote:
On Monday, May 29, 2017 20:00:12 Stanislav Blinov via
Digitalmars-d wrote:
On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
> On Monday, May 29, 2017 17:19:27 Stanislav Blinov via
>
> Digitalmars-d wrote:
>> `in` is `
On Monday, May 29, 2017 21:13:53 Stanislav Blinov via Digitalmars-d wrote:
> On Monday, 29 May 2017 at 20:31:18 UTC, Jonathan M Davis wrote:
> > On Monday, May 29, 2017 20:00:12 Stanislav Blinov via
> >
> > Digitalmars-d wrote:
> >> On Monday, 29 May 2017 at 19:14:54 UTC, Jonathan M Davis wrote:
>
On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote:
That definition currently there is more precise than the
definition on that page has been historically...
Apparently, it is not. Do you have a reference to Walter's change
regarding `in` becoming just `const`? Because a change l
On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote:
On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote:
That definition currently there is more precise than the
definition on that page has been historically...
Apparently, it is not. Do you have a reference to Walter'
On Tuesday, 30 May 2017 at 09:48:09 UTC, Petar Kirov [ZombineDev]
wrote:
On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote:
On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis
wrote:
That definition currently there is more precise than the
definition on that page has been
On Tuesday, 30 May 2017 at 09:55:14 UTC, Petar Kirov [ZombineDev]
wrote:
Unfortunately, `in` was never implemented as `scope const`. I
think it was only when Walter started working actively on
scope that he found out that it's too late to change this -
https://github.com/dlang/dmd/pull/5898. H
On 05/30/2017 05:48 AM, Petar Kirov [ZombineDev] wrote:
On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote:
On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote:
That definition currently there is more precise than the definition
on that page has been historically...
On Tuesday, 30 May 2017 at 15:59:04 UTC, Andrei Alexandrescu
wrote:
On 05/30/2017 05:48 AM, Petar Kirov [ZombineDev] wrote:
On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov
wrote:
On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis
wrote:
That definition currently there is more
On 05/30/2017 12:11 PM, Stanislav Blinov wrote:
On Tuesday, 30 May 2017 at 15:59:04 UTC, Andrei Alexandrescu wrote:
On 05/30/2017 05:48 AM, Petar Kirov [ZombineDev] wrote:
On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote:
On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis
On 05/30/2017 12:19 PM, Andrei Alexandrescu wrote:
On 05/30/2017 12:11 PM, Stanislav Blinov wrote:
On Tuesday, 30 May 2017 at 15:59:04 UTC, Andrei Alexandrescu wrote:
On 05/30/2017 05:48 AM, Petar Kirov [ZombineDev] wrote:
On Tuesday, 30 May 2017 at 06:13:39 UTC, Stanislav Blinov wrote:
On Tu
On Tuesday, 30 May 2017 at 16:19:26 UTC, Andrei Alexandrescu
wrote:
Apparently, it is not. Do you have a reference to Walter's
change regarding `in` becoming just `const`? ...
Unfortunately, `in` was never implemented as `scope const`.
Why would it need to be `const`? Thanks! -- Andrei
Wha
On Tuesday, May 30, 2017 06:13:39 Stanislav Blinov via Digitalmars-d wrote:
> On Tuesday, 30 May 2017 at 02:12:56 UTC, Jonathan M Davis wrote:
> > That definition currently there is more precise than the
> > definition on that page has been historically...
>
> Apparently, it is not. Do you have a r
47 matches
Mail list logo
