On Friday, 14 February 2014 at 00:42:08 UTC, Adam D. Ruppe wrote:
I'd like to see typeinfo moved completely to the library. The
language would then not depend on it directly. The point of
this thread is to see how practical it is. Here's the changes I
have in mind:
I'm thinking about trying t
On Sunday, 13 July 2014 at 15:30:59 UTC, Trass3r wrote:
Any news on this?
I haven't messed around with it since the winter and probably
won't be able to for a while. (The current setup works well
enough for me anyway...)
On Sunday, 13 July 2014 at 15:30:59 UTC, Trass3r wrote:
Any news on this?
It's waiting on you or I to do the implementation and submit a
pull request. If it needs to be me, it'll probably be done
sometime towards the end of 2016. And that assumes the current
desire to fossilize D doesn't p
Any news on this?
On Friday, 14 February 2014 at 00:42:08 UTC, Adam D. Ruppe wrote:
I'd like to see typeinfo moved completely to the library. The
language would then not depend on it directly. The point of
this thread is to see how practical it is. Here's the changes I
have in mind:
1) Stop automatic generatio
On 2014-02-18 03:16, Daniel Murphy wrote:
That would be a runtime use of 'foo', to get the function pointer.
Other modules can get the function pointer as well. Or perhaps that's
what you're saying.
--
/Jacob Carlborg
"Jacob Carlborg" wrote in message news:ldtrf3$14t0$1...@digitalmars.com...
On 2014-02-17 17:01, Kenji Hara wrote:
> - modue private functions
>// Compiler can elide codegen for 'foo', if other declarations
>// in module a don't use it for runtime code.
Private functions can be called
On 2014-02-17 17:01, Kenji Hara wrote:
- modue private functions
module a;
private string foo() { ... }
enum x = foo();
// Compiler can elide codegen for 'foo', if other declarations
// in module a don't use it for runtime code.
Private functions can be called from other module
Am Tue, 18 Feb 2014 01:01:18 +0900
schrieb Kenji Hara :
> In some case it would be possible without WPO/LTO:
>
> - Immediately called lambdas
>
> enum x = (){ return some_sort_ctfe_calculartions; }; // lambda
> codegen is unnecessary.
>
> - modue private functions
>
> module a;
> priva
On Monday, 17 February 2014 at 16:01:50 UTC, Kenji Hara wrote:
- Immediately called lambdas
enum x = (){ return some_sort_ctfe_calculartions; }; //
lambda codegen
is unnecessary.
True but this is only one of many cases.
- modue private functions
module a;
private string foo() { ..
17-Feb-2014 17:48, Dicebot пишет:
On Monday, 17 February 2014 at 09:33:01 UTC, Max Samukha wrote:
But that's an awful dangerous hack. A better solution is needed.
I have been thinking about addition of something like
`pragma(nocodegen)` to the language. Should be simple to implement and
can fi
2014-02-18 0:48 GMT+09:00 Dicebot :
> On Monday, 17 February 2014 at 14:51:20 UTC, Kenji Hara wrote:
>
>> If a function is only used for CTFE, compiler can elide its codegen. It's
>> in the scope of optimization.
>>
>
> It can't know for sure it without some sort of WPO / LTO - and those won't
> h
On Monday, 17 February 2014 at 14:51:20 UTC, Kenji Hara wrote:
If a function is only used for CTFE, compiler can elide its
codegen. It's
in the scope of optimization.
It can't know for sure it without some sort of WPO / LTO - and
those won't happen any time soon. I propose a simple workaround
If a function is only used for CTFE, compiler can elide its codegen. It's
in the scope of optimization.
Kenji Hara
2014-02-17 22:48 GMT+09:00 Dicebot :
> On Monday, 17 February 2014 at 09:33:01 UTC, Max Samukha wrote:
>
>> But that's an awful dangerous hack. A better solution is needed.
>>
>
>
On Monday, 17 February 2014 at 09:33:01 UTC, Max Samukha wrote:
But that's an awful dangerous hack. A better solution is needed.
I have been thinking about addition of something like
`pragma(nocodegen)` to the language. Should be simple to
implement and can fix some of most crazy bloat issues
On Friday, 14 February 2014 at 20:05:53 UTC, Rainer Schuetze
wrote:
The only drawback I see is that it makes compilation a bit
slower and pollutes object files with code just executed during
CTFE.
Currently, the bloat can be reduced like this:
void foo()
{
if (__ctfe)
{
// functio
Walter Bright:
On 2/13/2014 4:42 PM, Adam D. Ruppe wrote:
If I'm not missing anything, these three changes would let us
completely define
(or not define) type info in the library without breaking
anything we have now!
It's a good idea worth exploring.
And at this stage of the D life it's a
On Sunday, 16 February 2014 at 20:19:13 UTC, Walter Bright wrote:
It's a good idea worth exploring.
Walter, I'm glad you voiced your opinion on this.
In my opinion, this should be a prerequisite to the minimalD
ideas that are currently being discussed. While I don't want to
ask you to step
On 2/13/2014 4:42 PM, Adam D. Ruppe wrote:
If I'm not missing anything, these three changes would let us completely define
(or not define) type info in the library without breaking anything we have now!
It's a good idea worth exploring.
Am 14.02.2014 16:32, schrieb Adam D. Ruppe:
On Friday, 14 February 2014 at 09:09:42 UTC, Benjamin Thaut wrote:
But that would mean that you have to pull the implementation of casts
and other features that rely on TypeInfo right now into the library too.
They already are: druntime/src/rt/cast_.
On 2014-02-14 01:42, Adam D. Ruppe wrote:
I think the others are already possible:
string TypeInfoImpl!T.toString() { return T.stringof; }
interface TypeInfo {} /* TypeInfoImpl(T) : TypeInfo */
Currently what .stringof evaluates to and the format of it is not
specified and should not be reli
On 14.02.2014 01:42, Adam D. Ruppe wrote:
I'd like to see typeinfo moved completely to the library. The language
would then not depend on it directly. The point of this thread is to see
how practical it is. Here's the changes I have in mind:
1) Stop automatic generation of TypeInfo.
2) typeid
On Friday, 14 February 2014 at 09:09:42 UTC, Benjamin Thaut wrote:
But that would mean that you have to pull the implementation of
casts and other features that rely on TypeInfo right now into
the library too.
They already are: druntime/src/rt/cast_.d I wouldn't change that,
I'm more thinking
On Friday, 14 February 2014 at 11:26:42 UTC, Mike wrote:
I think Adam would have to clarify what he meant by "the
library".
You got it.
On Friday, 14 February 2014 at 09:09:42 UTC, Benjamin Thaut wrote:
But that would mean that you have to pull the implementation of
casts and other features that rely on TypeInfo right now into
the library too. Do you really think this such a good idea? My
biggest concern with this is, that when
But that would mean that you have to pull the implementation of casts
and other features that rely on TypeInfo right now into the library too.
Do you really think this such a good idea? My biggest concern with this
is, that when TypeInfo is pulled into phobos, the implementation of
TypeInfo is
I'd like to see typeinfo moved completely to the library. The
language would then not depend on it directly. The point of this
thread is to see how practical it is. Here's the changes I have
in mind:
1) Stop automatic generation of TypeInfo.
2) typeid(T) in the language now returns a static i
27 matches
Mail list logo
