On Wednesday, February 06, 2013 02:38:17 Andrei Alexandrescu wrote:
> Probably it'll need a fair amount of tweaking. Anyhow it's in
> destroyable form.
>
> http://wiki.dlang.org/DIP25
Overall, the ref part seems good, but I'm highly skeptical of the part on
addresses.
The main point I'd raise a
On Wednesday, 6 February 2013 at 21:40:00 UTC, Andrei
Alexandrescu wrote:
On 2/6/13 3:02 PM, Andrej Mitrovic wrote:
Also the DIP argues that addressOf solves the @property issue
w.r.t.
return values. I've proposed we use an .addressOf property
which only
works on @property functions, and I saw
Am Wed, 06 Feb 2013 22:11:40 -0800
schrieb Walter Bright :
> On 2/6/2013 4:23 PM, Andrej Mitrovic wrote:
> > On 2/6/13, Andrei Alexandrescu wrote:
> >> Pointers are what they are, and they're not appropriate for
> >> code that offers guarantees.
> >
> > But we're talking about @system here. I wou
Two more things:
Disable a read/write propa like int getSetSomeInteger(int).
int getSomeInteger() and void setSomeIntger(int) only allowed.
And disable default parameter for setter.
On 02/08/2013 02:06 AM, deadalnix wrote:
On Friday, 8 February 2013 at 06:28:54 UTC, Chad Joan wrote:
Destroy!
The cost of passing a delegate is way higher than the cost of passing
the extra pointer. Delegate cause an opaque function call so :
- All registers that the callee is allowed to tr
On Friday, 8 February 2013 at 06:28:54 UTC, Chad Joan wrote:
On 02/06/2013 02:38 AM, Andrei Alexandrescu wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
A single delegate (closure) can be used to defer both r
On 02/06/2013 02:38 AM, Andrei Alexandrescu wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
A single delegate (closure) can be used to defer both reads and writes
on an arbitrary expression.
This works on n
On Thursday, 7 February 2013 at 19:57:50 UTC, Walter Bright wrote:
On 2/7/2013 3:16 AM, deadalnix wrote:
The 'funny' things is that C#'s would cause syntax problem
issue with address
of,
where D does.
I don't understand this sentence.
In C#, foo.bar won't execute bar's method of foo. It wi
On Thursday, 7 February 2013 at 14:43:38 UTC, Steven
Schveighoffer wrote:
On Thu, 07 Feb 2013 01:06:34 -0500, Walter Bright
wrote:
The only time (now) that you can take the address of function
return value is if that is a return by ref. So, if taking the
address of a ref is disallowed, the
On Thursday, 7 February 2013 at 19:49:27 UTC, Walter Bright wrote:
On 2/7/2013 6:15 AM, Zach the Mystic wrote:
Can you tell me if you consider my proposal with regard to
making ref safe and
complete simple and intuitive both for compiler and user, and
if not, why? (I
don't have an opinion abou
On 2/7/2013 3:16 AM, deadalnix wrote:
The 'funny' things is that C#'s would cause syntax problem issue with address
of,
where D does.
I don't understand this sentence.
In C#, foo.bar won't execute bar's method of foo. It will get what is called in
D a delegate. foo.bar() execute that delegat
On 2/7/2013 6:15 AM, Zach the Mystic wrote:
Can you tell me if you consider my proposal with regard to making ref safe and
complete simple and intuitive both for compiler and user, and if not, why? (I
don't have an opinion about '&' yet.)
http://forum.dlang.org/thread/ket199$2c27$1...@digitalmar
On Thursday, 7 February 2013 at 09:21:38 UTC, deadalnix wrote:
On Thursday, 7 February 2013 at 08:48:30 UTC, Rob T wrote:
On Thursday, 7 February 2013 at 05:54:29 UTC, deadalnix wrote:
On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:
In other words @safe should explicitly mean "I here
Am Thu, 07 Feb 2013 09:04:29 +0100
schrieb "deadalnix" :
> On Thursday, 7 February 2013 at 07:41:57 UTC, Johannes Pfau wrote:
> > Am Wed, 06 Feb 2013 23:45:51 +0100
> > schrieb Robert :
> >
> >> What happened to the scope storage class for parameters.
> >>
> >> Wouldn't this solve the problems, w
On Thu, 07 Feb 2013 01:06:34 -0500, Walter Bright
wrote:
The only time (now) that you can take the address of function return
value is if that is a return by ref. So, if taking the address of a ref
is disallowed, then the syntax is no longer ambiguous.
Thinking about this, I don't know
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:
DIP25 aim to solve the ref issue. Which is clearly useful.
Conflating that goal
with making previous DIP on function call is only going to
export the mess in
another area of the language.
This is the very example of why simplic
On Wed, 06 Feb 2013 17:36:24 -, Andrei Alexandrescu
wrote:
A good part of that is the recent debate on what &func should do (take
the address of the function vs. the address of its result). With the
unsafe meaning out of the way, only the safe one is eligible.
&X takes the address of X
On Thursday, 7 February 2013 at 10:32:38 UTC, Walter Bright wrote:
On 2/7/2013 2:05 AM, deadalnix wrote:
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright
wrote:
The point is, there must always be a balance of competing
interests. That's
certainly true here.
That is an assertion not
The solution to this problem has been posted already many times, simply
allow fields to be marked with @property too, having the compiler lower
it to a private field with trivial setter/getter method.
As I already mentioned, I don't really see the point of properties at
all, if they are not interc
On 2/7/2013 2:05 AM, deadalnix wrote:
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:
The point is, there must always be a balance of competing interests. That's
certainly true here.
That is an assertion not an argument.
Try designing anything by using one overriding princi
On Thursday, 7 February 2013 at 06:36:22 UTC, H. S. Teoh wrote:
D ref types are currently highly crippled because of the
inability to
declare ref variables, which mandates ugly workarounds. It
should be a
first-class type qualifier IMO. (Yes I know it's currently a
*function*
qualifier, not a t
On Thursday, 7 February 2013 at 09:23:20 UTC, Walter Bright wrote:
The point is, there must always be a balance of competing
interests. That's certainly true here.
That is an assertion not an argument.
Does C# always allow taking the address of a getter's return
value? I don't know, but I'd
On Thursday, 7 February 2013 at 08:48:30 UTC, Rob T wrote:
On Thursday, 7 February 2013 at 05:54:29 UTC, deadalnix wrote:
On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:
In other words @safe should explicitly mean "I hereby verify
that the code is safe" not "I will silently re-write
On 2/7/2013 12:22 AM, deadalnix wrote:
Ok, why should "as much as possible" be the goal? There are other
considerations - what merit should they have?
I don't think anyone have interest to get back on that. If you have another
answer to that question, please share.
The point is, there must al
On Thursday, 7 February 2013 at 05:54:29 UTC, deadalnix wrote:
On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:
In other words @safe should explicitly mean "I hereby verify
that the code is safe" not "I will silently re-write your code
in unknown ways to make it safe".
@safe never
On Thursday, 7 February 2013 at 06:23:10 UTC, Walter Bright wrote:
On 2/6/2013 10:13 PM, deadalnix wrote:
It is a given that @properties can't 100M emulate field, but
the goal should be
to close he gap as much as possible.
Ok, why should "as much as possible" be the goal? There are
other con
Am Wed, 06 Feb 2013 02:38:17 -0500
schrieb Andrei Alexandrescu :
> Probably it'll need a fair amount of tweaking. Anyhow it's in
> destroyable form.
>
> http://wiki.dlang.org/DIP25
>
>
> Thanks,
>
> Andrei
Regarding the questions about scope parameters and allowing & in system
code, wouldn't
On Thursday, 7 February 2013 at 07:41:57 UTC, Johannes Pfau wrote:
Am Wed, 06 Feb 2013 23:45:51 +0100
schrieb Robert :
What happened to the scope storage class for parameters.
Wouldn't this solve the problems, with the simple rule that
you are
not allowed to pass transient objects by referenc
Am Wed, 06 Feb 2013 23:45:51 +0100
schrieb Robert :
> What happened to the scope storage class for parameters.
>
> Wouldn't this solve the problems, with the simple rule that you are
> not allowed to pass transient objects by reference if the parameter
> was not declared with scope? And if I unde
On 2/7/13 1:34 AM, H. S. Teoh wrote:
On Wed, Feb 06, 2013 at 10:09:48PM -0800, Walter Bright wrote:
On 2/6/2013 8:16 PM, Marco Leise wrote:
As for the address taking, I hope it doesn't end up in being
nannied to much by the language. Like in the case with printf,
it could really piss people off
On Wed, Feb 06, 2013 at 10:09:48PM -0800, Walter Bright wrote:
> On 2/6/2013 8:16 PM, Marco Leise wrote:
> >As for the address taking, I hope it doesn't end up in being
> >nannied to much by the language. Like in the case with printf,
> >it could really piss people off that don't understand the
> >
On 2/6/2013 10:13 PM, deadalnix wrote:
It is a given that @properties can't 100M emulate field, but the goal should be
to close he gap as much as possible.
Ok, why should "as much as possible" be the goal? There are other considerations
- what merit should they have?
For example, I consider
On Thursday, 7 February 2013 at 06:13:44 UTC, deadalnix wrote:
It doesn't change anything in many cases. Especially for
template alias parameters. It doesn't change the intrinsic
complexity of the proposal that conflate a function (as first
class object), its return value, and the useless C/C++
On 2/6/2013 4:23 PM, Andrej Mitrovic wrote:
On 2/6/13, Andrei Alexandrescu wrote:
Pointers are what they are, and they're not appropriate for
code that offers guarantees.
But we're talking about @system here. I would probably be fine with
these rules if they only applied to @safe.
I feel lik
On 2/6/2013 8:16 PM, Marco Leise wrote:
As for the address taking, I hope it doesn't end up in being
nannied to much by the language. Like in the case with printf,
it could really piss people off that don't understand the
reasoning behind it. Make the error message informative for
that: "Potentia
On Thursday, 7 February 2013 at 06:06:56 UTC, Walter Bright wrote:
On 2/6/2013 7:30 PM, deadalnix wrote:
The limitation on address taking seriously impair the
possibility of
implementing @property properly to emulate a field.
Properties are always going to be subsets of fields. For
example,
On 2/6/2013 7:30 PM, deadalnix wrote:
The limitation on address taking seriously impair the possibility of
implementing @property properly to emulate a field.
Properties are always going to be subsets of fields. For example,
@property int foo() { return 3; }
is never going to work with tr
On Thursday, 7 February 2013 at 05:43:24 UTC, Rob T wrote:
In other words @safe should explicitly mean "I hereby verify
that the code is safe" not "I will silently re-write your code
in unknown ways to make it safe".
@safe never meant that and Andrei never suggested that.
On Thursday, 7 February 2013 at 05:37:44 UTC, Rob T wrote:
On Wednesday, 6 February 2013 at 22:14:42 UTC, Andrei
Alexandrescu wrote:
On 2/6/13 5:05 PM, Timon Gehr wrote:
On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:
It would be more consistent with C++, but less so with the
notion of
safe
On Wednesday, 6 February 2013 at 22:14:42 UTC, Andrei
Alexandrescu wrote:
On 2/6/13 5:05 PM, Timon Gehr wrote:
On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:
It would be more consistent with C++, but less so with the
notion of
safety. I find it very consistent that all uses of
&expression
Am Wed, 06 Feb 2013 02:38:17 -0500
schrieb Andrei Alexandrescu :
> Probably it'll need a fair amount of tweaking. Anyhow it's in
> destroyable form.
>
> http://wiki.dlang.org/DIP25
>
>
> Thanks,
>
> Andrei
At first I was skeptical about how this would work with binary
operator overloads wher
On Wednesday, 6 February 2013 at 07:38:17 UTC, Andrei
Alexandrescu wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Seems like a good DIP overall.
The limitation on address taking seriously impair the possibility
o
On Wednesday, 6 February 2013 at 22:33:57 UTC, Andrei
Alexandrescu wrote:
On 2/6/13 5:22 PM, Timon Gehr wrote:
I see. Generally?
Eg. this detects the escape and allocates as well?:
S* foo()@safe{
S s;
return &s;
}
I think I'm starting to see what you're doing there :o).
I have to admit thi
What happened to the scope storage class for parameters.
Wouldn't this solve the problems, with the simple rule that you are not
allowed to pass transient objects by reference if the parameter was not
declared with scope? And if I understood correctly, the compiler is
already capable of locally en
On 2/6/13 5:26 PM, Jakob Ovrum wrote:
On Wednesday, 6 February 2013 at 07:38:17 UTC, Andrei Alexandrescu wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
I'm not sure why it's trying to safe-up pointers.
Disa
On 2/6/13 5:22 PM, Timon Gehr wrote:
I see. Generally?
Eg. this detects the escape and allocates as well?:
S* foo()@safe{
S s;
return &s;
}
I think I'm starting to see what you're doing there :o).
Andrei
On Wednesday, 6 February 2013 at 07:38:17 UTC, Andrei
Alexandrescu wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
I'm not sure why it's trying to safe-up pointers.
Disallowing the & operator on stack variab
On 02/06/2013 11:14 PM, Andrei Alexandrescu wrote:
On 2/6/13 5:05 PM, Timon Gehr wrote:
On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:
It would be more consistent with C++, but less so with the notion of
safety. I find it very consistent that all uses of &expression are safe,
and this is th
On 2/6/13 5:05 PM, Timon Gehr wrote:
On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:
It would be more consistent with C++, but less so with the notion of
safety. I find it very consistent that all uses of &expression are safe,
and this is the kind of consistency Walter and I believe is worth
On 02/06/2013 08:12 PM, Andrei Alexandrescu wrote:
On 2/6/13 1:39 PM, Benjamin Thaut wrote:
Am 06.02.2013 18:50, schrieb Andrei Alexandrescu:
On 2/6/13 12:40 PM, Benjamin Thaut wrote:
So the &value expression would only be left for taking addresses of
functions? Wouldn't it make more sense to
On 2/6/13 3:02 PM, Andrej Mitrovic wrote:
On 2/6/13, Andrei Alexandrescu wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Originally I thought addressOf was only planned for safe functions,
but for system too?
This will likely
On 2/6/13, Andrei Alexandrescu wrote:
> Probably it'll need a fair amount of tweaking. Anyhow it's in
> destroyable form.
> http://wiki.dlang.org/DIP25
Originally I thought addressOf was only planned for safe functions,
but for system too?
This will likely break almost every library in existence.
On 2/6/13 1:39 PM, Benjamin Thaut wrote:
Am 06.02.2013 18:50, schrieb Andrei Alexandrescu:
On 2/6/13 12:40 PM, Benjamin Thaut wrote:
So the &value expression would only be left for taking addresses of
functions? Wouldn't it make more sense to do it the other way around?
E.g. create some utilty
On Wed, 06 Feb 2013 02:38:17 -0500, Andrei Alexandrescu
wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
First reaction:
It should be GUARANTEED that addressOf is a simple load of the underlying
pointer that ref represe
Am 06.02.2013 18:50, schrieb Andrei Alexandrescu:
On 2/6/13 12:40 PM, Benjamin Thaut wrote:
So the &value expression would only be left for taking addresses of
functions? Wouldn't it make more sense to do it the other way around?
E.g. create some utilty function that is only there for taking the
On Wednesday, 6 February 2013 at 17:50:06 UTC, Andrei
Alexandrescu wrote:
A good part of that is the recent debate on what &func should
do (take
the address of the function vs. the address of its result).
With the
unsafe meaning out of the way, only the safe one is eligible.
Added a dedicated
On 2/6/13 12:40 PM, Benjamin Thaut wrote:
So the &value expression would only be left for taking addresses of
functions? Wouldn't it make more sense to do it the other way around?
E.g. create some utilty function that is only there for taking the
address of functions and disallowing to do so by u
On 2/6/13 12:36 PM, Andrei Alexandrescu wrote:
On 2/6/13 12:33 PM, Benjamin Thaut wrote:
Am 06.02.2013 08:38, schrieb Andrei Alexandrescu:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
What I don't get is, why is
Am 06.02.2013 18:36, schrieb Andrei Alexandrescu:
On 2/6/13 12:33 PM, Benjamin Thaut wrote:
Am 06.02.2013 08:38, schrieb Andrei Alexandrescu:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
What I don't get is, why
On 2/6/13 12:33 PM, Benjamin Thaut wrote:
Am 06.02.2013 08:38, schrieb Andrei Alexandrescu:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
What I don't get is, why is it better to have a function
"addressOf(value)"
Am 06.02.2013 08:38, schrieb Andrei Alexandrescu:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
What I don't get is, why is it better to have a function
"addressOf(value)" that does exactly the same as &value? Exp
On 2/6/13 2:38 AM, Andrei Alexandrescu wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Updated with a section dedicated to address taking:
http://wiki.dlang.org/DIP25#Taking_address
Andrei
On 2/6/13 9:48 AM, Chad Joan wrote:
My interpretation so far is that the only difference between DIP25 and
current D code is that we won't be allowed to pass stack variables
(including by-value/copied parameters) into ref parameters.
Hmm, I need to make things clearer. That's covered plainly in
On 2/6/13 9:49 AM, Chad Joan wrote:
On 02/06/2013 09:48 AM, Chad Joan wrote:
Once I get to the "Typechecking rules" section and dig into the
nitty-gritty, it seems to be written in a way that discusses what is
allowed, but only briefly hints at what is disallowed. It is not
immediately clear to
On Wednesday, 6 February 2013 at 07:38:17 UTC, Andrei
Alexandrescu wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
All of the 'fine' ones are fine. Which leaves how one might
invoke the 'unfine' ones. The la
On 02/06/2013 02:38 AM, Andrei Alexandrescu wrote:
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
This is probably reasonably, but I'm having trouble fully comprehending it.
Once I get to the "Typechecking rules" s
On 02/06/2013 09:48 AM, Chad Joan wrote:
Once I get to the "Typechecking rules" section and dig into the
nitty-gritty, it seems to be written in a way that discusses what is
allowed, but only briefly hints at what is disallowed. It is not
immediately clear to me how this would impact my code.
Am Wed, 06 Feb 2013 02:38:17 -0500
schrieb Andrei Alexandrescu :
> Probably it'll need a fair amount of tweaking. Anyhow it's in
> destroyable form.
>
> http://wiki.dlang.org/DIP25
>
>
> Thanks,
>
> Andrei
Sounds good.
Regarding rule 2.2:
I think somebody already said that classes could be
2013/2/6 Andrei Alexandrescu
> Probably it'll need a fair amount of tweaking. Anyhow it's in destroyable
> form.
>
> http://wiki.dlang.org/DIP25
Hmm, this is much reasonable.
In recent, I had wrote and post a compiler extension to reinforce a kind of
trait which related to pure function. I cal
Probably it'll need a fair amount of tweaking. Anyhow it's in
destroyable form.
http://wiki.dlang.org/DIP25
Thanks,
Andrei
70 matches
Mail list logo
