On Monday, 20 June 2016 at 08:10:19 UTC, Dicebot wrote:
How about defining semantics like "try inlining if possible,
fallback to always emitting symbol to object file otherwise"?
That would also allow compatible implementation in dmd.
My reasoning for proposing that is that for all
On Tuesday, 21 June 2016 at 10:39:52 UTC, David Nadlinger wrote:
On Monday, 20 June 2016 at 08:10:19 UTC, Dicebot wrote:
How about defining semantics like "try inlining if possible,
fallback to always emitting symbol to object file otherwise"?
That would also allow compatible implementation in
On Tuesday, 21 June 2016 at 10:34:01 UTC, pineapple wrote:
On Tuesday, 21 June 2016 at 10:28:03 UTC, pineapple wrote:
On Tuesday, 21 June 2016 at 02:59:44 UTC, ZombineDev wrote:
I think it would be good idea to take this even further:
T4 foo(T4, T0, T1, Ts..., T2, T3)(T0 t0, T1 t1, Args args,
On Monday, 20 June 2016 at 08:10:19 UTC, Dicebot wrote:
How about defining semantics like "try inlining if possible,
fallback to always emitting symbol to object file otherwise"?
That would also allow compatible implementation in dmd.
This would get rid of the undefined symbols, but there is
On Tuesday, 21 June 2016 at 10:28:03 UTC, pineapple wrote:
On Tuesday, 21 June 2016 at 02:59:44 UTC, ZombineDev wrote:
I think it would be good idea to take this even further:
T4 foo(T4, T0, T1, Ts..., T2, T3)(T0 t0, T1 t1, Args args, T2
t2, T3 t3)
In other words, I think that the
On Tuesday, 21 June 2016 at 02:59:44 UTC, ZombineDev wrote:
I think it would be good idea to take this even further:
T4 foo(T4, T0, T1, Ts..., T2, T3)(T0 t0, T1 t1, Args args, T2
t2, T3 t3)
In other words, I think that the limitation that variadic
template parameter list must be at the end
On Tuesday, 21 June 2016 at 02:59:44 UTC, ZombineDev wrote:
On Monday, 20 June 2016 at 14:28:06 UTC, Jacob Carlborg wrote:
On 2016-06-19 12:43, Dicebot wrote:
Yes. It is necessary because runtime parameter list is
variadic -
template bloat in such cases is usually eliminated by
forwarding to
On Monday, 20 June 2016 at 14:28:06 UTC, Jacob Carlborg wrote:
On 2016-06-19 12:43, Dicebot wrote:
Yes. It is necessary because runtime parameter list is
variadic -
template bloat in such cases is usually eliminated by
forwarding to
another private method immediately turning file/line into
On Monday, 20 June 2016 at 14:28:06 UTC, Jacob Carlborg wrote:
Would it be a bad idea to allow this in the compiler:
void foo(Args...)(Args args, string file = __FILE__, size_t
line = __LINE__);
It wouldn't be possible to pass "file" or "line" when calling
"foo". But it's useful for the
On 2016-06-19 12:43, Dicebot wrote:
Yes. It is necessary because runtime parameter list is variadic -
template bloat in such cases is usually eliminated by forwarding to
another private method immediately turning file/line into first runtime
argument instead.
Would it be a bad idea to allow
On 06/20/2016 01:13 AM, Johan Engelen wrote:
> On Sunday, 19 June 2016 at 21:40:20 UTC, David Nadlinger wrote:
>> On Sunday, 19 June 2016 at 21:13:00 UTC, Johan Engelen wrote:
>>> On Sunday, 19 June 2016 at 21:11:59 UTC, Johan Engelen wrote:
(I think we can pretty much inline anything the
On Saturday, 18 June 2016 at 18:13:22 UTC, Johan Engelen wrote:
An example of how __FILE__ as template parameter will break
your library:
In library, distributed in binary+source form:
```
alias file_templ_alias = file_templ!bool;
T file_templ(T, string file = __FILE__, size_t line = __LINE__)
On Sunday, 19 June 2016 at 21:40:20 UTC, David Nadlinger wrote:
On Sunday, 19 June 2016 at 21:13:00 UTC, Johan Engelen wrote:
On Sunday, 19 June 2016 at 21:11:59 UTC, Johan Engelen wrote:
(I think we can pretty much inline anything the user throws
at us)
(as long as it is not a naked asm
On Sunday, 19 June 2016 at 21:13:00 UTC, Johan Engelen wrote:
On Sunday, 19 June 2016 at 21:11:59 UTC, Johan Engelen wrote:
(I think we can pretty much inline anything the user throws at
us)
(as long as it is not a naked asm function)
Another example is `alloca`, which you might not want to
On Sunday, 19 June 2016 at 21:11:59 UTC, Johan Engelen wrote:
(I think we can pretty much inline anything the user throws at
us)
(as long as it is not a naked asm function)
On Sunday, 19 June 2016 at 20:37:02 UTC, Dicebot wrote:
On 06/19/2016 11:33 AM, Johan Engelen wrote:
On Sunday, 19 June 2016 at 08:06:09 UTC, Dicebot wrote:
This important feature and can't be simply removed. For
example, std.experimental.logger also relies on it.
Do you mean it relies on
On 06/19/2016 11:33 AM, Johan Engelen wrote:
> On Sunday, 19 June 2016 at 08:06:09 UTC, Dicebot wrote:
>> This important feature and can't be simply removed. For example,
>> std.experimental.logger also relies on it.
>
> Do you mean it relies on __FILE__ being a template parameter (instead of
> a
On Sunday, 19 June 2016 at 08:33:40 UTC, Johan Engelen wrote:
On Sunday, 19 June 2016 at 08:06:09 UTC, Dicebot wrote:
This important feature and can't be simply removed. For
example, std.experimental.logger also relies on it.
Do you mean it relies on __FILE__ being a template parameter
On Sunday, 19 June 2016 at 08:06:09 UTC, Dicebot wrote:
This important feature and can't be simply removed. For
example, std.experimental.logger also relies on it.
Do you mean it relies on __FILE__ being a template parameter
(instead of a runtime default parameter, like enforce)?
It needs
This important feature and can't be simply removed. For example,
std.experimental.logger also relies on it. It needs to be fixed
instead.
Two immediate workarounds that come to mmy mind:
1. Make __FILE__ relative to import path
2. Always emit new symbol to object file if __FILE__ is involved
An example of how __FILE__ as template parameter will break your
library:
In library, distributed in binary+source form:
```
alias file_templ_alias = file_templ!bool;
T file_templ(T, string file = __FILE__, size_t line = __LINE__)
(T value) {
return value;
}
```
In user code, linking to
21 matches
Mail list logo
