On 28.01.2018 02:13, Jonathan M Davis wrote:
Yes, but you can have that problem even without getting inheritance involve.
For instance,
class C
{
immutable string s;
this()
{
s = foo();
}
string foo()
{
return s ~ "foo";
}
}
When foo is cal
On 28/01/18 03:13, Jonathan M Davis wrote:
On Saturday, January 27, 2018 19:42:26 Steven Schveighoffer via Digitalmars-
d wrote:
Well, a virtual function may expect that the ctor has been run, and
expect that members are different from their init values.
Yes, but you can have that problem even
On Saturday, January 27, 2018 19:42:26 Steven Schveighoffer via Digitalmars-
d wrote:
> Well, a virtual function may expect that the ctor has been run, and
> expect that members are different from their init values.
Yes, but you can have that problem even without getting inheritance involve.
For i
On 1/27/18 12:01 PM, Jonathan M Davis wrote:
On Saturday, January 27, 2018 16:18:26 Thomas Mader via Digitalmars-d wrote:
On Saturday, 27 January 2018 at 14:48:08 UTC, Johan Engelen wrote:
I'm working on devirtualization and for that it's crucial to
know some spec details (or define them in the
On Saturday, January 27, 2018 16:18:26 Thomas Mader via Digitalmars-d wrote:
> On Saturday, 27 January 2018 at 14:48:08 UTC, Johan Engelen wrote:
> > I'm working on devirtualization and for that it's crucial to
> > know some spec details (or define them in the spec if they
> > aren't yet).
> >
> >
On Saturday, 27 January 2018 at 16:18:26 UTC, Thomas Mader wrote:
Can't answer your question but have a little question.
How is the behavior different to the situation in C++?
In C++, the dynamic type of an object changes during construction
and destruction (e.g. base class ctor calls base cl
On Saturday, 27 January 2018 at 14:48:08 UTC, Johan Engelen wrote:
I'm working on devirtualization and for that it's crucial to
know some spec details (or define them in the spec if they
aren't yet).
Currently, calling non-final member functions in the destructor
is allowed and these indirect
I'm working on devirtualization and for that it's crucial to know
some spec details (or define them in the spec if they aren't yet).
Currently, calling non-final member functions in the destructor
is allowed and these indirect calls are to the possibly
overridden functions of derived classes.
On 1 March 2015 at 18:57, Matthias Bentrup via Digitalmars-d
wrote:
> On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote:
>>
>> On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei Alexandrescu wrote:
>>>
>>> Defines a significantly better function call protocol:
>>>
>>> http://wiki.d
On 2015-03-01 14:15, Daniel Murphy wrote:
Because a compiler recognized UDA is an additional complication for
something that is unlikely to be a problem for anyone. Do you have code
with methods named opAddRef? No? Me neither.
I don't agree. If those are the final names, no. But I do have m
On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote:
class RcType {...}
void fun(RcType1 c, RcType1 d);
auto x = new RcType;
fun(x, x);
If the compiler were smart, it would realize that by splitting
parameters this way, it's actually adding an additional
reference to x. The funct
On Sunday, 1 March 2015 at 08:57:17 UTC, Matthias Bentrup wrote:
Note that you can get the same issue without duplicate
parameters, if you pass an alias to a global variable.
static A a;
void fun(A x) {
a = null; // Releases x
x.func();
}
void main() {
a = new A();
fun(a);
}
Well do
On Mon, 02 Mar 2015 00:15:02 +1100, Daniel Murphy wrote:
> "Jacob Carlborg" wrote in message news:mcv342$2c9t$1...@digitalmars.com...
>
>> I already commented on that. Andrei said [1] he was fine with breaking
>> code for this feature. I don't understand why because it so easy to fix
>> with a c
"Jacob Carlborg" wrote in message news:mcv342$2c9t$1...@digitalmars.com...
I already commented on that. Andrei said [1] he was fine with breaking
code for this feature. I don't understand why because it so easy to fix
with a compiler recognized UDA [2].
Because a compiler recognized UDA is a
On 2015-03-01 10:41, Paulo Pinto wrote:
What about having an UDA or a mixin for marking the types as RCO?
I already commented on that. Andrei said [1] he was fine with breaking
code for this feature. I don't understand why because it so easy to fix
with a compiler recognized UDA [2].
[1] h
On 2015-03-01 13:41, Andrei Alexandrescu wrote:
We prefer opAddRef/opRelease to define an RCO, same as
empty/front/popFront define a range. -- Andrei
I don't see how a UDA would hurt.
--
/Jacob Carlborg
On 2015-02-28 22:12, Andrei Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Is there any checking that the signatures of these methods matches the
ones in the base class if an implicit conversion to the base class is
made? Example:
cla
On 3/1/15 1:41 AM, Paulo Pinto wrote:
On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Andrei
What about having an UDA or a mixin for marking the types as RCO?
We prefer opAddRef/opR
On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei
Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Andrei
What about having an UDA or a mixin for marking the types as RCO?
--
Paulo
On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote:
On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei
Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Andrei
This is obviously much better, Andrei.
I think an alternative s
On 2/28/15 11:04 PM, Zach the Mystic wrote:
keep track of this from the caller's side.
Thanks, I'll keep that in mind. -- Andrei
On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei
Alexandrescu wrote:
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Andrei
This is obviously much better, Andrei.
I think an alternative solution (I know -- another idea --
against my own first idea!) i
Defines a significantly better function call protocol:
http://wiki.dlang.org/DIP74
Andrei
On 2012-48-15 06:12, Jonathan M Davis wrote:
I don't see any reason not to support it. if you want coversion to only
go one
way, then alias a function which returns the value being aliased rather
than
aliasing a variable. If it doesn't support implicit conversions from
other
types, then it
On Thursday, December 13, 2012 15:25:10 Simen Kjaeraas wrote:
> As discussed deep in the thread "Is there any reason why arithmetic
> operation
> on shorts and bytes return int?"[1], D currently does not support this
> behavior:
>
> struct bbyte {
> byte b;
> alias b this;
> }
>
> void
12/13/2012 6:25 PM, Simen Kjaeraas пишет:
As discussed deep in the thread "Is there any reason why arithmetic
operation
on shorts and bytes return int?"[1], D currently does not support this
behavior:
struct bbyte {
byte b;
alias b this;
}
void foo(bbyte b) {}
void baz() {
byte
On Thursday, 13 December 2012 at 16:15:16 UTC, Simen Kjaeraas
wrote:
But this is easily solved:
Hmmm, indeed. This might just work then...
On 2012-28-13 17:12, d coder wrote:
I do not know if I am missing something but consider:
struct Foo {
int r;
int i;
bool get() {
return true; // always return true
}
alias get this;
}
So I am wondering how it would be possible to construct Foo from a bool?
Otherwise how would
I do not know if I am missing something but consider:
struct Foo {
int r;
int i;
bool get() {
return true; // always return true
}
alias get this;
}
So I am wondering how it would be possible to construct Foo from a bool?
Otherwise how would the compiler be able to figure out in wh
On 2012-38-13 15:12, Adam D. Ruppe wrote:
On Thursday, 13 December 2012 at 14:25:27 UTC, Simen Kjaeraas wrote:
foo(b); // Cannot implicitly convert byte to bbyte.
I think the way it is now is correct for alias this.. it is kinda like
implicitly casting to a base class. That's correct,
On Thursday, 13 December 2012 at 14:25:27 UTC, Simen Kjaeraas
wrote:
foo(b); // Cannot implicitly convert byte to bbyte.
I think the way it is now is correct for alias this.. it is kinda
like implicitly casting to a base class. That's correct, but
going to a superclass isn't necessarily r
On 09/23/2012 07:37 PM, Andrej Mitrovic wrote:
On 9/7/12, Kevin McTaggart wrote:
snip
There's one thing nobody mentioned yet, and that is that we're already
using this syntax in the language -- in foreach loops:
struct Foo { int x; }
Foo[] arr = [{4}, {5}, {6}];
foreach (idx, ref val; arr)
On 9/7/12, Kevin McTaggart wrote:
> snip
There's one thing nobody mentioned yet, and that is that we're already
using this syntax in the language -- in foreach loops:
struct Foo { int x; }
Foo[] arr = [{4}, {5}, {6}];
foreach (idx, ref val; arr)
{
val.x = idx;
}
However I'd like to see a c
I'm amazed and very pleased at the discussion that this has
generated. I think it would be great if ref and out required for
function calls in D3. As others have mentioned, it would greatly
assist with code readability.
On Friday, 7 September 2012 at 11:33:41 UTC, Kevin McTaggart
On 09/18/2012 11:26 PM, Ziad Hatahet wrote:
On Mon, Sep 10, 2012 at 1:36 PM, Timon Gehr mailto:timon.g...@gmx.ch>> wrote:
Yes, Go uses explicit pointer types.
Regarding Rust, you are wrong.
I have built the latest Rust compiler.
import io;
fn modify(&a:int){
a = 2
On Mon, Sep 10, 2012 at 1:36 PM, Timon Gehr wrote:
>
> Yes, Go uses explicit pointer types.
> Regarding Rust, you are wrong.
> I have built the latest Rust compiler.
>
> import io;
>
> fn modify(&a:int){
> a = 2;
> }
> fn swap(&a:T,&b:T){
>let tmp<-a;
>a<-b;
>b<-tmp;
> }
>
>
The `
On Friday, 14 September 2012 at 06:55:00 UTC, F i L wrote:
On Thursday, 13 September 2012 at 22:21:34 UTC, ixid wrote:
Couldn't this easily be supported by an IDE by coloured
function arguments based on their type? Then the information
is clearly visible without cluttering the code.
no becaus
It'd be great if the guy doing Visual D could give it a try. We
could also resolve the property vs function issue in a similar
manner to avoid the need to enforce unnecessary brackets
everywhere. It would seem like a more practical approach than
breaking all D2 code that actually addresses the
On Friday, 14 September 2012 at 22:20:16 UTC, Manuel wrote:
On Friday, 14 September 2012 at 06:55:00 UTC, F i L wrote:
On Thursday, 13 September 2012 at 22:21:34 UTC, ixid wrote:
Couldn't this easily be supported by an IDE by coloured
function arguments based on their type? Then the information
On 12/09/2012 13:55, Nick Treleaven wrote:
On 12/09/2012 13:39, Nick Treleaven wrote:
class Bar { int b; }
void changeBar(ref Bar b) { b = new Bar(); }
void warning()
{
Bar bar = new Bar();
bar.b = 10;
bar.changeBar(); // Warning: 'bar' is implicitly passed by
reference. To elimin
On 13/09/2012 16:29, David Piepgrass wrote:
On Thursday, 13 September 2012 at 15:01:28 UTC, Andrei Alexandrescu wrote:
On 9/13/12 10:53 AM, David Piepgrass wrote:
Walter and I have discussed this for quite a while. We have recently
decided to disallow, at least in SafeD, escaping the address of
On Thursday, 13 September 2012 at 22:21:34 UTC, ixid wrote:
Couldn't this easily be supported by an IDE by coloured
function arguments based on their type? Then the information is
clearly visible without cluttering the code.
no because... wait... that... that could work.
On 2012-09-13 18:28, Sean Kelly wrote:
I love the idea. However, this could complicate working with C APIs,
particularly regarding structs which are often passed by reference as a matter
of course. For example:
struct some_c_struct {}
void fn(ref some_c_struct s) {
some_c_func(&s);
}
Couldn't this easily be supported by an IDE by coloured function
arguments based on their type? Then the information is clearly
visible without cluttering the code.
On Thursday, 13 September 2012 at 10:34:00 UTC, Andrei
Alexandrescu wrote:
On 9/13/12 1:02 AM, Manuel wrote:
If a bigger part of the D community would like to have these
annotations
added to the language, at least as an optional feature, then
that might
persuade our "benevolent dictators" (just
On Thursday, 13 September 2012 at 15:18:06 UTC, Jonathan M Davis
wrote:
On Thursday, September 13, 2012 12:34:34 Andrei Alexandrescu
wrote:
I don't think there would be problems with allowing ref/out
optionally
at the call site. The thing is, however, that in this matter
reasonable
people may
On Thursday, September 13, 2012 17:47:45 David Piepgrass wrote:
> It gives *who* a false sense of security? If it's optional then I
> *know* lack of ref/out doesn't imply that the parameter won't
> change. Only people who don't know the rules would have this
> false sense of security.
More like an
On Sep 13, 2012, at 7:21 AM, Andrei Alexandrescu
wrote:
>
> One question Walter and I thought about a lot was whether we should disallow
> escaping addresses of ref parameters in general or only in @safe code. We
> decided to go for the latter in order to avoid breakage of existing code.
> T
On Thursday, 13 September 2012 at 16:29:19 UTC, Andrei
Alexandrescu wrote:
It gives *who* a false sense of security?
It's "whom".
Andrei
P.S. All of my life I've been waiting for this moment!!!
LOL
On 9/13/12 11:47 AM, David Piepgrass wrote:
I really think that optionally allowing ref and out at the call site
is more
damaging than beneficial. _Requiring_ it could be beneficial, since
then you
know that the arguments are being taken by ref, but if it's optional,
it gives
you a false sense of
I really think that optionally allowing ref and out at the call
site is more
damaging than beneficial. _Requiring_ it could be beneficial,
since then you
know that the arguments are being taken by ref, but if it's
optional, it gives
you a false sense of security and can be misleading.
It give
On Thursday, 13 September 2012 at 15:01:28 UTC, Andrei
Alexandrescu wrote:
On 9/13/12 10:53 AM, David Piepgrass wrote:
Walter and I have discussed this for quite a while. We have
recently
decided to disallow, at least in SafeD, escaping the address
of a ref
parameter. In the beginning we'll be
On Thursday, September 13, 2012 12:34:34 Andrei Alexandrescu wrote:
> I don't think there would be problems with allowing ref/out optionally
> at the call site. The thing is, however, that in this matter reasonable
> people may disagree.
I really think that optionally allowing ref and out at the c
On 9/13/12 10:53 AM, David Piepgrass wrote:
Walter and I have discussed this for quite a while. We have recently
decided to disallow, at least in SafeD, escaping the address of a ref
parameter. In the beginning we'll be overly conservative by
disallowing taking the address of a ref altogether. I'
I don't think there would be problems with allowing ref/out
optionally at the call site. The thing is, however, that in
this matter reasonable people may disagree.
I'd be unable to identify any pattern in engineers choosing one
preference over the other.
Maybe C++ fans prefer pointers or impli
On Thursday, 13 September 2012 at 10:34:00 UTC, Andrei
Alexandrescu wrote:
The thing is, however, that in this matter reasonable people
may disagree.
Sounds exactly like the C# lambda syntax situation.
On 9/13/12 6:58 AM, Namespace wrote:
In D:
class A { // or struct
A(ref int host) : _host(&host) { }
private:
int* _host;
}
Since when do we have initialization lists in D? ;)
Oops, sorry :o).
at topic: +1
One question Walter and I thought about a lot was whether we should
disallow escap
In D:
class A { // or struct
A(ref int host) : _host(&host) { }
private:
int* _host;
}
Since when do we have initialization lists in D? ;)
at topic: +1
On 9/13/12 1:02 AM, Manuel wrote:
If a bigger part of the D community would like to have these annotations
added to the language, at least as an optional feature, then that might
persuade our "benevolent dictators" (just joking - you are great!)
Walther and Andrei to add them or we could just mak
errors ;-)
Kevin just put this up for discussion because he realized while
porting code from C# to D that he got wrong function calls on
overloaded functions because of missing call site parameter
annotations and just asked about the general opinion in the D
community to add these to the langu
Minas wrote:
Anyway, who needs to see f(ref x) when you can put your mouse
above the function call and see its declaration? All modern
IDEs support that - and I don't think C# guys use plain text
editors.
People debugging large bodies of code should not be required to
hover the mouse over ea
Minas:
g(&x); // passed by reference as well, but it is not explicit
like before. You don't even know if it's a const pointer if you
don't read the function's signature.
The presence of "&" at call site acts exactly like the "ref" at
the call site. In both cases you don't know if it's
const/i
I disagree that it would be useful.
In C# it is useful because pointers that used a lot less than in
D.
Consider this:
void f(ref int x)
{
...
}
...
int x = 5;
f(ref x); // good, passed by reference
...
But:
void g(int* p)
{
...
}
...
int x = 5;
g(&x); // passed by reference as well, but i
On 12/09/2012 13:39, Nick Treleaven wrote:
class Bar { int b; }
void changeBar(ref Bar b) { b = new Bar(); }
void warning()
{
Bar bar = new Bar();
bar.b = 10;
bar.changeBar(); // Warning: 'bar' is implicitly passed by
reference. To eliminate this warning, use 'changeBar(ref bar)' i
On 11/09/2012 18:57, David Piepgrass wrote:
void func (ref int[], int)
If ref/out were required at the call site, this destroys UFCS.
int[] array;
array.func(0); // error, ref not specified by caller
For UFCS, ref should be implied.
+1
Why? UFCS means uniform function call syntax.
It is a
On Tuesday, 11 September 2012 at 16:49:45 UTC, Manuel wrote:
On Tuesday, 11 September 2012 at 08:10:21 UTC, Andrei
Alexandrescu wrote:
On 9/11/12 1:28 AM, Manuel wrote:
Citation? I'm using C# 5.0 with Visual Studios 2012 on
Windows 8 right
now and ref/out are still required at the call sight of
hen the
reference to the class was passed by value. But it is far
easier to keep track of which classes are mutable than to keep
track of which parameters of which functions are 'ref', because
functions far outnumber classes.)
+1
It's not only that you yourself want to
On Tue, 11 Sep 2012 13:36:23 +0200
Sönke Ludwig wrote:
> Am 08.09.2012 20:17, schrieb Timon Gehr:
> > Agh, sent a private mail again. I don't seem to be the only one
> > though. Has there been a thunderbird UI change?
> >
>
> They exchanged the order of the "Reply" and "Smart reply" buttons in
void func (ref int[], int)
If ref/out were required at the call site, this destroys UFCS.
int[] array;
array.func(0); // error, ref not specified by caller
For UFCS, ref should be implied.
+1
Why? UFCS means uniform function call syntax.
It is already understood that the thing left of '.' m
Actually the darndest thing is that C# has retired the syntax
in 5.0 (it used to be required up until 4.0). Apparently users
complained it was too unsightly.
Andrei
Wh-huh?? Reference please. I have sought out info about C# 5
multiple times and I never heard that.
Anyway I don't mind if re
On Tuesday, 11 September 2012 at 08:10:21 UTC, Andrei
Alexandrescu wrote:
On 9/11/12 1:28 AM, Manuel wrote:
Citation? I'm using C# 5.0 with Visual Studios 2012 on
Windows 8 right
now and ref/out are still required at the call sight of
functions.
I have Visual Studio 2012 RC and can confirm, t
On 10/09/2012 21:36, Timon Gehr wrote:
On 09/09/2012 02:54 PM, Nick Treleaven wrote:
On 08/09/2012 19:17, Timon Gehr wrote:
On 09/08/2012 06:05 PM, Nick Treleaven wrote:
On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
Given:
void func (ref int[], int)
If ref/out were required at the call
Am 08.09.2012 20:17, schrieb Timon Gehr:
> Agh, sent a private mail again. I don't seem to be the only one though.
> Has there been a thunderbird UI change?
>
They exchanged the order of the "Reply" and "Smart reply" buttons in TB
15. This also hit me several times, very annoying. You can switch
On 9/11/12 1:28 AM, Manuel wrote:
Citation? I'm using C# 5.0 with Visual Studios 2012 on Windows 8 right
now and ref/out are still required at the call sight of functions.
I have Visual Studio 2012 RC and can confirm, that ref and out
are still required even with C# 5.0 (but maybe there is some
On 11-09-2012 06:21, zerg wrote:
But i have to admit, that it might be too late for changes in D2
regarding this just because it would break too much existing code
Such feature can be implemented as optional in D2 with compiler switch
to enforce explicit ref and out syntax.
It's already highly
But i have to admit, that it might be too late for changes in D2
regarding this just because it would break too much existing code
Such feature can be implemented as optional in D2 with compiler
switch to enforce explicit ref and out syntax.
j1, out int j2)
I note that the second function calls another function as
follows:
int positionStart = 1;
parseLineInts(text, positionStart, j0, j1, j2);
I look forward to seeing feedback from D experts. This is the
only significant change that I could think of recommending for
the language.
On 09/09/2012 02:54 PM, Nick Treleaven wrote:
On 08/09/2012 19:17, Timon Gehr wrote:
On 09/08/2012 06:05 PM, Nick Treleaven wrote:
On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
Given:
void func (ref int[], int)
If ref/out were required at the call site, this destroys UFCS.
int[] array;
On 08/09/2012 19:17, Timon Gehr wrote:
On 09/08/2012 06:05 PM, Nick Treleaven wrote:
On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
Given:
void func (ref int[], int)
If ref/out were required at the call site, this destroys UFCS.
int[] array;
array.func(0); // error, ref not specified by c
On Fri, 07 Sep 2012 13:34:02 +0200
"Kevin McTaggart" wrote:
> I suggest that the language require ref and out when
> calling functions, as C# requires.
That's one thing I've always thought C# got better than D. I'd love to
see D fixed in this regard, and I've argued in favor of it
some time ago
Agh, sent a private mail again. I don't seem to be the only one though.
Has there been a thunderbird UI change?
On 09/08/2012 06:05 PM, Nick Treleaven wrote:
On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
Given:
void func (ref int[], int)
If ref/out were required at the call site, this des
On Saturday, September 08, 2012 17:05:25 Nick Treleaven wrote:
> As an option it would serve no practical purpose other than documentation.
It's worse than that. It's not even documentation that you can trust. If it
were optional, and ref were used in a function call, then you know that the
argu
and would also eliminate the problem I
had when the wrong function from the following choices was
mistakenly called:
parseLineInts(string text, int positionStart, out int j0, out
int j1)
parseLineInts(string text, out int j0, out int j1, out int j2)
I note that the second function calls anot
Nick Treleaven:
IMO it's only functions whose arguments are all passed by ref
that don't really need annotation, and these are infrequent.
All others stand to benefit.
For arguments that use "const ref", "in ref", "immutable ref" I
think ref at the call site is not so important.
Bye,
bearo
On 08/09/2012 14:05, Chris Nicholson-Sauls wrote:
Given:
void func (ref int[], int)
If ref/out were required at the call site, this destroys UFCS.
int[] array;
array.func(0); // error, ref not specified by caller
For UFCS, ref should be implied. Also for 'const ref' parameters,
callsite ref
Given:
void func (ref int[], int)
If ref/out were required at the call site, this destroys UFCS.
int[] array;
array.func(0); // error, ref not specified by caller
Or would one expect something like:
(ref array).func(0);
...put simply, I hope not.
This suggestion has come up a couple times b
On 2012-09-07 13:34, Kevin McTaggart wrote:
I've been looking at migrating a reasonably large ship motion library
(tens of thousands of lines) from C# to D. I've become quite
enthusiastic about D, and most of my problems have been relatively minor
(e.g., inconsistent bugs with std.container.Arra
On Friday, 7 September 2012 at 16:46:36 UTC, bearophile wrote:
Andrei Alexandrescu:
Actually the darndest thing is that C# has retired the syntax
in 5.0 (it used to be required up until 4.0). Apparently users
complained it was too unsightly.
Are you sure?
This page about the Visual Studio 20
Andrei Alexandrescu:
Actually the darndest thing is that C# has retired the syntax
in 5.0 (it used to be required up until 4.0). Apparently users
complained it was too unsightly.
Are you sure?
This page about the Visual Studio 2012 shows that ref and out are
required:
http://msdn.microsoft.
On 09/07/2012 05:51 PM, Timon Gehr wrote:
How do they deal with the increased ambiguity in overload resolution?
Actually, it is simple. They just have to call the non-out overload
when there is no out at the call site, regardless of the actual
argument.
On 09/07/2012 04:38 PM, Andrei Alexandrescu wrote:
...
Actually the darndest thing is that C# has retired the syntax in 5.0 (it
used to be required up until 4.0). Apparently users complained it was
too unsightly.
Andrei
How do they deal with the increased ambiguity in overload resolution?
Am 07.09.2012 16:38, schrieb Andrei Alexandrescu:
Actually the darndest thing is that C# has retired the syntax in 5.0 (it
used to be required up until 4.0). Apparently users complained it was
too unsightly.
reference link?
On Friday, September 07, 2012 13:34:02 Kevin McTaggart wrote:
> I look forward to seeing feedback from D experts. This is the
> only significant change that I could think of recommending for
> the language.
Regardless of the pros and cons of requiring explicit ref and out, it would
break a lot o
On 9/7/12 4:55 PM, Andrej Mitrovic wrote:
On 9/7/12, Andrei Alexandrescu wrote:
Actually the darndest thing is that C# has retired the syntax in 5.0 (it
used to be required up until 4.0). Apparently users complained it was
too unsightly.
If you like implicit ref then why did you choose to use
On 9/7/12, Andrei Alexandrescu wrote:
> Actually the darndest thing is that C# has retired the syntax in 5.0 (it
> used to be required up until 4.0). Apparently users complained it was
> too unsightly.
If you like implicit ref then why did you choose to use pointers when
implementing std.getopt?
I had when the wrong
function from the following choices was mistakenly called:
parseLineInts(string text, int positionStart, out int j0, out int j1)
parseLineInts(string text, out int j0, out int j1, out int j2)
I note that the second function calls another function as follows:
int po
nction from the following choices was mistakenly
called:
parseLineInts(string text, int positionStart, out int j0, out int
j1)
parseLineInts(string text, out int j0, out int j1, out int j2)
I note that the second function calls another function as follows:
int positionStart = 1;
parseLineInts(text, po
On 29.01.2010 05:20, Steven Schveighoffer wrote:
Andrei Alexandrescu Wrote:
Michiel Helvensteijn wrote:
> Andrei Alexandrescu wrote:
>
foreach (line; stdin.byLine()) { ... }
vs.
foreach (line; stdin.byLine) { ... }
How do I choose?
>>> byLine
dsimcha:
> Yea, can anyone even come up with a good Devil's Advocate argument in favor of
> leaving these in? The best one I can think of is that, since arrays in D are
> builtin, the basic functionality for them should also be builtin so they feel
> "first-class". This is a pretty weak argument.
== Quote from Don (nos...@nospam.com)'s article
> Nick Sabalausky wrote:
> > "Pelle Månsson" wrote in message
> > news:hjv9sf$1n5...@digitalmars.com...
> >> On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
> >>> Note in the anecdote above, both users would have
> >>> been satisfied if you could
1 - 100 of 278 matches
Mail list logo
