I filed a bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=8603
On Friday, 31 August 2012 at 05:24:31 UTC, Tommi wrote:
...But, actually it seems that the language is a bit broken,
because it doesn't follow neither one of those two options.
What it actually does is this:
Obviously I don't think that the language is broken, but the
compiler is. I wrote t
On Thursday, 30 August 2012 at 17:50:47 UTC, Jonathan M Davis
wrote:
On Thursday, August 30, 2012 15:30:15 Tommi wrote:
Yes, but to me the ambiguity of that example is in whether or
not
implicit deferencing of pointers has precedence over uniform
function call syntax. Apparently it does, but it
On Thursday, August 30, 2012 15:30:15 Tommi wrote:
> Yes, but to me the ambiguity of that example is in whether or not
> implicit deferencing of pointers has precedence over uniform
> function call syntax. Apparently it does, but it's not that
> obvious that it would.
It _can't_ work any other way
On Thursday, 30 August 2012 at 11:53:14 UTC, bearophile wrote:
Tommi:
// This prints 1, so we called the actual method
I think in D methods have precedence over free functions.
Bye,
bearophile
Yes, but to me the ambiguity of that example is in whether or not
implicit deferencing of poi
Tommi:
// This prints 1, so we called the actual method
I think in D methods have precedence over free functions.
Bye,
bearophile
On Thursday, 30 August 2012 at 08:57:24 UTC, Tommi wrote:
On Thursday, 30 August 2012 at 07:35:34 UTC, Namespace wrote:
struct MyStruct
{
// ref int defaultInitRef; // Illegal: reference variables
// can't be default initialized
But you can handle it like const
On Thursday, 30 August 2012 at 07:35:34 UTC, Namespace wrote:
struct MyStruct
{
// ref int defaultInitRef; // Illegal: reference variables
// can't be default initialized
But you can handle it like const members: you have to
initialize these members in the ct
On Thursday, 30 August 2012 at 07:35:34 UTC, Namespace wrote:
I had totally forgotten what it says in "The book" about
struct and class construction. It's basically that all fields
are first initialized to either T.init or by using the field's
initializer. That means the use of ref inside cla
I had totally forgotten what it says in "The book" about struct
and class construction. It's basically that all fields are
first initialized to either T.init or by using the field's
initializer. That means the use of ref inside class or struct
would be quite restricted:
int globalVal;
stru
I think references should either take the C# approach (which is
rock-solid), or the C++ approach (which is also pretty
rock-solid), but not an in-between.
...although, now I'm thinking that having reference variables as
members of struct or class won't ever work. And that's because
T.init is a compile-time variable, and references can't be known
at compile-time (unlike pointers, which can be null). Perhaps the
easiest way to implement reference v
...but I guess you could do this:
int globalVal1;
int globalVal2;
struct MyStruct(alias valToRef)
{
ref int refVal = valToRef;
}
void main()
{
MyStruct!globalVal1 ms1;
MyStruct!globalVal2 ms2;
}
On Wednesday, 29 August 2012 at 21:37:33 UTC, Era Scarecrow wrote:
struct R {
ref int r;
this(ref int i) {r = i;}
}
I had totally forgotten what it says in "The book" about struct
and class construction. It's basically that all fields are first
initialized to either T.init or by using
On Wednesday, 29 August 2012 at 19:55:08 UTC, Tommi wrote:
I honestly don't know anything about memory safety and what it
entails. So, I can't comment about any of that stuff. But if
you say general ref variables can't be implemented in @safe
mode, then I can just take your word for it. But wha
On Wednesday, 29 August 2012 at 14:17:21 UTC, Era Scarecrow wrote:
Then most of my examples change to going into the constructor
rather than out, and the global one goes away. But it still
doesn't help with the problem of anything stack allocated.
struct S {
//default construtor otherwise
On Wednesday, 29 August 2012 at 15:49:26 UTC, Namespace wrote:
*References cannot be null, whereas pointers can; every
reference refers to some object, although it may or may not be
valid. Note that for this reason, containers of references are
not allowed.
* References cannot be uninitialize
*References cannot be null, whereas pointers can; every
reference refers to some object, although it may or may not be
valid. Note that for this reason, containers of references are
not allowed.
* References cannot be uninitialized. Because it is impossible
to reinitialize a reference, they m
On Wednesday, 29 August 2012 at 12:41:26 UTC, Tommi wrote:
I think we might be talking about somewhat different things.
What I mean by reference variable is what the term means in
C++. From wikipedia:
http://en.wikipedia.org/wiki/Reference_%28C%2B%2B%29
C++ references differ from pointers in
On Wednesday, 29 August 2012 at 02:57:27 UTC, Era Scarecrow wrote:
Assuming 'ref' works:
struct S {
ref int r;
}
//ref local variable/stack, Ticking timebomb
//compiler may refuse
void useRef(ref S input, int r) {
input.r = r;
}
I think we might be talking about somewhat differen
On Wednesday, 29 August 2012 at 04:54:31 UTC, Tommi wrote:
On Wednesday, 29 August 2012 at 03:17:39 UTC, Era Scarecrow
I think that's right; Otherwise ref wouldn't be allowed in
@safe code (at all).
But couldn't the compiler disallow all unsafe ref use in @safe
code, and allow all use of ref
Am Tue, 28 Aug 2012 22:08:11 -0700
schrieb Jonathan M Davis :
> On Wednesday, August 29, 2012 06:46:25 Tommi wrote:
> > The weird thing is that you can use a member access operator with
> > a pointer (without explicitly dereferencing the pointer first).
>
> Well, you clearly haven't done much poi
On Wednesday, August 29, 2012 02:04:44 Nick Sabalausky wrote:
> Out of curiosity, what about "MyStruct**" or "MyClass*"?
I'd have to try it, but my guess would be that it only implicitly dereferences
one level (though in the case of MyClass*, that might be enough, since there's
no dereferencing
On Tue, 28 Aug 2012 22:08:11 -0700
Jonathan M Davis wrote:
> On Wednesday, August 29, 2012 06:46:25 Tommi wrote:
> > The weird thing is that you can use a member access operator with
> > a pointer (without explicitly dereferencing the pointer first).
>
> Well, you clearly haven't done much point
On Wednesday, August 29, 2012 06:46:25 Tommi wrote:
> The weird thing is that you can use a member access operator with
> a pointer (without explicitly dereferencing the pointer first).
Well, you clearly haven't done much pointers to structs in D, or that wouldn't
be surprising at all. . always i
On Wednesday, 29 August 2012 at 03:17:39 UTC, Era Scarecrow wrote:
To add on to this a little.. If you can only ref by calling,
you ensure the variable is alive/valid when you are calling it
regardless if it's stack or heap or global (But can't ensure it
once the scope ends). Making a referenc
On Wednesday, 29 August 2012 at 03:21:04 UTC, Jonathan M Davis
wrote:
>> > void main()
>> > {
>> >
>> > immutable(Test)* ptr = new immutable(Test);
>> > ptr.foo();
>> >
>> > }
>>
>> Now, that's a surprise for someone coming from C++. But even
>> though ptr looks like a reference varia
On Wednesday, August 29, 2012 04:40:17 anonymous wrote:
> On Wednesday, 29 August 2012 at 02:07:19 UTC, Nick Sabalausky
>
> wrote:
> > On Wed, 29 Aug 2012 03:16:20 +0200
> >
> > "Tommi" wrote:
> >> On Wednesday, 29 August 2012 at 00:34:02 UTC, cal wrote:
> >> > On Wednesday, 29 August 2012 at 00
On Wednesday, 29 August 2012 at 02:57:27 UTC, Era Scarecrow wrote:
You would need a flag added to EVERY variable and item to
specify if it was stack allocated or not. Otherwise it would be
quite annoying to deal with. The compiler has to work blindly,
assuming everything is correct. You can ref
On Wednesday, 29 August 2012 at 01:28:49 UTC, Jonathan M Davis
wrote:
On Wednesday, August 29, 2012 02:21:28 Tommi wrote:
Foreach loops can make reference variables, and function calls
can do it for the parameters passed in. So, my question is,
wouldn't it be better if we could, in general, mak
On Wednesday, 29 August 2012 at 02:07:19 UTC, Nick Sabalausky
wrote:
On Wed, 29 Aug 2012 03:16:20 +0200
"Tommi" wrote:
On Wednesday, 29 August 2012 at 00:34:02 UTC, cal wrote:
> On Wednesday, 29 August 2012 at 00:21:29 UTC, Tommi wrote:
>> In this situation, I think, the most convenient and
>
I think there's an (undocumented?) Ref class in some file
(object_.d?)
On Wednesday, 29 August 2012 at 02:28:09 UTC, Mehrdad wrote:
I think there's an (undocumented?) Ref class in some file
(object_.d?)
er, struct
On Wed, 29 Aug 2012 03:44:38 +0200
"Tommi" wrote:
> On Wednesday, 29 August 2012 at 01:28:49 UTC, Jonathan M Davis
> wrote:
> > Not going to happen. Unfortunately though, I don't remember all
> > of Walter's reasons for it, so I can't really say why (partly
> > due to complications it causes in
On Wed, 29 Aug 2012 03:16:20 +0200
"Tommi" wrote:
> On Wednesday, 29 August 2012 at 00:34:02 UTC, cal wrote:
> > On Wednesday, 29 August 2012 at 00:21:29 UTC, Tommi wrote:
> >> In this situation, I think, the most convenient and sensible
> >> thing to do is to make a reference to the data, and u
On Wednesday, 29 August 2012 at 01:42:36 UTC, Timon Gehr wrote:
Not exactly the same thing (what you propose would have
different
IFTI behaviour), but works quite well:
import std.stdio;
struct Ref(T){
private T* _payload;
this(ref T i){_payload = &i; }
@property ref T deref(){ ret
On Wednesday, 29 August 2012 at 01:28:49 UTC, Jonathan M Davis
wrote:
Not going to happen. Unfortunately though, I don't remember all
of Walter's reasons for it, so I can't really say why (partly
due to complications it causes in the language, I think, but I
don't know).
I'd really like to hea
Not exactly the same thing (what you propose would have different
IFTI behaviour), but works quite well:
import std.stdio;
struct Ref(T){
private T* _payload;
this(ref T i){_payload = &i; }
@property ref T deref(){ return *_payload; }
alias deref this;
}
auto ref_(T)(ref T arg){r
On Wednesday, August 29, 2012 02:21:28 Tommi wrote:
> Foreach loops can make reference variables, and function calls
> can do it for the parameters passed in. So, my question is,
> wouldn't it be better if we could, in general, make reference
> variables?
Not going to happen. Unfortunately though,
On Wednesday, 29 August 2012 at 00:34:02 UTC, cal wrote:
On Wednesday, 29 August 2012 at 00:21:29 UTC, Tommi wrote:
In this situation, I think, the most convenient and sensible
thing to do is to make a reference to the data, and use that
reference multiple times. We could make a pointer, but th
On Wednesday, 29 August 2012 at 00:21:29 UTC, Tommi wrote:
In this situation, I think, the most convenient and sensible
thing to do is to make a reference to the data, and use that
reference multiple times. We could make a pointer, but then
we'd be stuck with the nasty syntax of dereferencing:
In the following example code there's a situation, where the data
we're looking for already exists, the data has value semantics,
finding the data takes quite a lot of time, we need to "use" the
data on multiple occasions, and the size of the data is so large
that we don't want to copy it.
In
42 matches
Mail list logo
