On 8/5/16 6:17 AM, Manu via Digitalmars-d wrote:
On 5 August 2016 at 03:33, Seb via Digitalmars-d
wrote:
On Thursday, 4 August 2016 at 12:44:49 UTC, Manu wrote:
On 29 July 2016 at 16:51, Jonathan M Davis via Digitalmars-d
wrote:
[...]
Bingo! But it's much deeper than that. ref is a disa
On 5 August 2016 at 03:33, Seb via Digitalmars-d
wrote:
> On Thursday, 4 August 2016 at 12:44:49 UTC, Manu wrote:
>>
>> On 29 July 2016 at 16:51, Jonathan M Davis via Digitalmars-d
>> wrote:
>>>
>>> [...]
>>
>>
>> Bingo! But it's much deeper than that. ref is a disaster. Use it to
>> any real ext
On Friday, 5 August 2016 at 08:40:04 UTC, ketmar wrote:
p.s. the only "gotcha" i see is if prototyp declaration is found
*after* the actual function was declared. as D code should not
depend of declaration order, this should be either error, or
(better!) use prototype to "fix" previous definiti
On Friday, 5 August 2016 at 08:15:37 UTC, Ethan Watson wrote:
So that's technically a bug. But. Before I go running off to
the Bugzilla Walter made. Should a user declaring and then
later defining a function be forced to 100% replicate that
function definition before defining it? If yes, then t
On Thursday, 4 August 2016 at 11:41:00 UTC, Jacob Carlborg wrote:
That works for me [1]. It was reported by Manu and fixed in
2012 [2].
I did some more experimenting, and it turns out that the problem
is when the declaration and definition have different linkage.
Being C++ functions means tha
On Thursday, 4 August 2016 at 12:44:49 UTC, Manu wrote:
On 29 July 2016 at 16:51, Jonathan M Davis via Digitalmars-d
wrote:
[...]
Bingo! But it's much deeper than that. ref is a disaster. Use
it to
any real extent; in particular, binding (or fabricating
bindings) to
extern(C++) code, and yo
On 29 July 2016 at 19:55, Walter Bright via Digitalmars-d
wrote:
> On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
>>
>> I've always looked at D's ref as being essentially the same as C++'s &
>> except that it's not considered to be part of the type, just attached to
>> it
>> in a
On 29 July 2016 at 16:51, Jonathan M Davis via Digitalmars-d
wrote:
> On Friday, July 29, 2016 08:29:19 Timon Gehr via Digitalmars-d wrote:
>> On 29.07.2016 06:52, Jonathan M Davis via Digitalmars-d wrote:
>> > On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:
>> >> My parser a
On 29 July 2016 at 07:34, Steven Schveighoffer via Digitalmars-d
wrote:
> On 7/28/16 4:16 PM, Jonathan M Davis via Digitalmars-d wrote:
>>
>> On Thursday, July 28, 2016 01:49:35 Walter Bright via Digitalmars-d wrote:
>>>
>>> On 7/28/2016 1:33 AM, Ethan Watson wrote:
1) Declaring a functi
On 2016-07-28 10:33, Ethan Watson wrote:
4) Forward declaring a function prototype means I can never declare that
function elsewhere (say, for example, with a mixin)
You mean like this:
import std.stdio;
void foo();
void foo()
{
writeln("asd");
}
void main()
{
foo();
}
That works
On Saturday, 30 July 2016 at 07:10:30 UTC, Timon Gehr wrote:
How does it not fix the problem? int function(int,int)ref is
the type of a ref-return function.
Because storage class binding are already ambiguous and
postfix ref is not accepted because it can only apply to the
type I
guess.
On 30.07.2016 04:49, deadalnix wrote:
On Friday, 29 July 2016 at 04:44:16 UTC, Timon Gehr wrote:
My parser accepts the following:
int function(int,int)ref functionPointer;
I wasn't really aware that this was illegal in DMD. (Other function
attributes, such as pure, are accepted.)
In fact, eve
On Friday, 29 July 2016 at 04:44:16 UTC, Timon Gehr wrote:
My parser accepts the following:
int function(int,int)ref functionPointer;
I wasn't really aware that this was illegal in DMD. (Other
function attributes, such as pure, are accepted.)
In fact, even the following is disallowed:
int fo
On 07/29/2016 03:55 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, July 29, 2016 14:14:49 Dicebot via Digitalmars-d wrote:
>> What you want it contradictory to the concept of "storage class".
>
> Why? I thought the the whole idea of "storage class" was that it was an
> attribute that w
On Friday, July 29, 2016 14:14:49 Dicebot via Digitalmars-d wrote:
> On 07/29/2016 02:05 PM, Jonathan M Davis via Digitalmars-d wrote:
> > On Friday, July 29, 2016 02:55:14 Walter Bright via Digitalmars-d wrote:
> >> On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
> >>> I've always
On Thursday, 28 July 2016 at 20:16:11 UTC, Jonathan M Davis wrote:
Well, if we decided to make parens with ref legal, then we
could make it work. e.g.
ref(int) function(int, int) functionPointer;
Now, I don't know of any other case where you'd actually use
parens with ref if it were legal, bu
On 7/29/16 12:44 AM, Timon Gehr wrote:
My parser accepts the following:
int function(int,int)ref functionPointer;
I wasn't really aware that this was illegal in DMD. (Other function
attributes, such as pure, are accepted.)
In fact, even the following is disallowed:
int foo(int)ref{}
Should
On 07/29/2016 02:05 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, July 29, 2016 02:55:14 Walter Bright via Digitalmars-d wrote:
>> On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
>>> I've always looked at D's ref as being essentially the same as C++'s &
>>> except that
On Friday, July 29, 2016 02:55:14 Walter Bright via Digitalmars-d wrote:
> On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
> > I've always looked at D's ref as being essentially the same as C++'s &
> > except that it's not considered to be part of the type, just attached to
> > it
>
On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
I've always looked at D's ref as being essentially the same as C++'s &
except that it's not considered to be part of the type, just attached to it
in a way that doesn't propagate. The same with with in or out. I just don't
see how it
On Friday, July 29, 2016 09:03:18 Timon Gehr via Digitalmars-d wrote:
> 'ref' has nothing to do with the type. This is not C++.
>
> The only thing that is inconsistent here is that 'ref' is not accepted
> on the right for function declarations.
ref may not be part of the type, but it just seems to
On 29.07.2016 08:51, Jonathan M Davis via Digitalmars-d wrote:
On Friday, July 29, 2016 08:29:19 Timon Gehr via Digitalmars-d wrote:
On 29.07.2016 06:52, Jonathan M Davis via Digitalmars-d wrote:
On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:
My parser accepts the follow
On Friday, July 29, 2016 08:29:19 Timon Gehr via Digitalmars-d wrote:
> On 29.07.2016 06:52, Jonathan M Davis via Digitalmars-d wrote:
> > On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:
> >> My parser accepts the following:
> >>
> >> int function(int,int)ref functionPointer;
On 29.07.2016 06:52, Jonathan M Davis via Digitalmars-d wrote:
On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:
My parser accepts the following:
int function(int,int)ref functionPointer;
I wasn't really aware that this was illegal in DMD. (Other function
attributes, such a
On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:
> My parser accepts the following:
>
> int function(int,int)ref functionPointer;
>
> I wasn't really aware that this was illegal in DMD. (Other function
> attributes, such as pure, are accepted.)
>
> In fact, even the following i
On 28.07.2016 10:49, Walter Bright wrote:
On 7/28/2016 1:33 AM, Ethan Watson wrote:
1) Declaring a function pointer with a ref return value can't be done
without
workarounds.
Try compiling this:
ref int function( int, int ) functionPointer;
It won't let you, because only parameters and for lo
On 7/28/16 4:16 PM, Jonathan M Davis via Digitalmars-d wrote:
On Thursday, July 28, 2016 01:49:35 Walter Bright via Digitalmars-d wrote:
On 7/28/2016 1:33 AM, Ethan Watson wrote:
1) Declaring a function pointer with a ref return value can't be done
without workarounds.
Try compiling this:
ref
On Thursday, 28 July 2016 at 20:16:11 UTC, Jonathan M Davis wrote:
Well, if we decided to make parens with ref legal, then we
could make it work. e.g.
ref(int) function(int, int) functionPointer;
Now, I don't know of any other case where you'd actually use
parens with ref if it were legal,
On Thursday, July 28, 2016 01:49:35 Walter Bright via Digitalmars-d wrote:
> On 7/28/2016 1:33 AM, Ethan Watson wrote:
> > 1) Declaring a function pointer with a ref return value can't be done
> > without workarounds.
> >
> > Try compiling this:
> >
> > ref int function( int, int ) functionPointer;
On Thursday, 28 July 2016 at 08:33:22 UTC, Ethan Watson wrote:
This also isn't the only use case I have. I'm a game engine
programmer. We write a lot of abstracted interfaces with
platform specific implementations. I know, I know, version(X){}
your code, right? But that's not how everyone works
On 7/28/2016 1:33 AM, Ethan Watson wrote:
I also assume "lodge a bug" will be the response to these.
Indeed. That's the process.
2) Expansion of code (static foreach, templates) is slow to the point where
string mixins are a legitimate compile-time optimisation
https://issues.dlang.org/sho
On 7/28/2016 1:54 AM, Ethan Watson wrote:
On Thursday, 28 July 2016 at 08:49:35 UTC, Walter Bright wrote:
Do you mean:
void foo();
void foo() { }
?
Exactly this. I've been unable to get it to work.
https://issues.dlang.org/show_bug.cgi?id=16329
The reason it's an enhancement request r
On Thursday, 28 July 2016 at 08:49:35 UTC, Walter Bright wrote:
Do you mean:
void foo();
void foo() { }
?
Exactly this. I've been unable to get it to work.
On 7/28/2016 1:33 AM, Ethan Watson wrote:
1) Declaring a function pointer with a ref return value can't be done without
workarounds.
Try compiling this:
ref int function( int, int ) functionPointer;
It won't let you, because only parameters and for loop symbols can be ref types.
Despite the fa
As mentioned in the D blog the other day, the binding system as
used by Remedy will both be open sourced and effectively
completely rewritten from when we shipped Quantum Break. As I'm
still deep within that rewrite, a bunch of things are still fresh
in my mind that aren't that great when it co
35 matches
Mail list logo
