August 23, 2013
On Friday, 23 August 2013 at 20:18:53 UTC, Timon Gehr wrote:
> On 08/23/2013 07:27 PM, Peter Alexander wrote:
>>>
>>
>> Or shared.
>>
>> Or const.
>>
>> Or scope.
>>
>> Or Object methods.
>>
>> There's quite a few unresolved issues!
>
> Add compile-time reflection.

The current compile-time reflection seems to be capable of doing most things to at least generate runtime reflection. What do you find missing with it? Or is it just the way it's presented?
August 23, 2013
On Fri, Aug 23, 2013 at 10:18:53PM +0200, Timon Gehr wrote:
> On 08/23/2013 07:27 PM, Peter Alexander wrote:
> >>
> >
> >Or shared.
> >
> >Or const.
> >
> >Or scope.
> >
> >Or Object methods.
> >
> >There's quite a few unresolved issues!
> 
> Add compile-time reflection.

I thought __traits solved that problem? In an ugly way, perhaps, but is there something that can't be solved with __traits?


T

-- 
Two wrongs don't make a right; but three rights do make a left...
August 23, 2013
On Friday, 23 August 2013 at 20:20:21 UTC, Timon Gehr wrote:
> On 08/23/2013 10:08 PM, Peter Alexander wrote:
>> On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
>>> What's the problem with const again?
>>
>> I'm thinking mainly of const postblit, and the ramifications of solving
>> that.
>
> What problem does const postblit have that a const constructor does not have?

Currently, const postblit completely breaks the type system.

struct Foo
{
    this(this) { *p = 2; }
    int* p;
}

void main()
{
    import std.stdio;
    immutable int i = 1;
    const(Foo) a = const(Foo)(&i);
    const(Foo) b = a;
    writeln(a.p, " ", *a.p);
    writeln(b.p, " ", *b.p);
    writeln(&i, " ", i);
}

For me, this gives:

7FFF5257D418 2
7FFF5257D418 2
7FFF5257D418 1

The immutable int is changed, and apparently the same address has two different values at the same time!

I'm not aware of any way to do this with constructors, but maybe I'm just not aware :-)
August 23, 2013
On Friday, 23 August 2013 at 20:42:20 UTC, H. S. Teoh wrote:
> On Fri, Aug 23, 2013 at 10:18:53PM +0200, Timon Gehr wrote:
>> On 08/23/2013 07:27 PM, Peter Alexander wrote:
>> > […]
>> >There's quite a few unresolved issues!
>> 
>> Add compile-time reflection.
>
> I thought __traits solved that problem? In an ugly way, perhaps, but is
> there something that can't be solved with __traits?

The problem is that the language does not define how to deal with "forward references". At all.

There are lots of cases where this matters in practice, for example when using the information obtained by __traits(allMembers, T) to add a new member to T (e.g. in a serialization library). But the canonical example probably is simply:
–––
static if (!is(typeof(b))) enum a = 0;
static if (!is(typeof(a))) enum b = 0;
// What is defined? a? b? both? Or is this illegal code?
–––

Right now, DMD is rather liberal in what it accepts, but what exactly is legal is not clear, and evaluation order is completely unspecified. This is a huge problem, as you end up writing a piece of code and seeing that it compiles fine and behaves as you would intuitively expect, assume that it is legal, only to have the compiler choke on it or behave differently when the next release comes out.

David
August 23, 2013
On Friday, August 23, 2013 22:20:21 Timon Gehr wrote:
> On 08/23/2013 10:08 PM, Peter Alexander wrote:
> > On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
> >> What's the problem with const again?
> > 
> > I'm thinking mainly of const postblit, and the ramifications of solving that.
> 
> What problem does const postblit have that a const constructor does not have?

A copy constructor creates a new object from scratch, so it doesn't modify anything, and creating it as const is fine. postblit on the other hand does a memcopy of the object first and then modifies select portions of the copy. When constructing a const or immutable object, that would mean that you have to modify a const or immutable object in order to mutate the portions that the postblit is supposed to be mutating. We need a way to construct a copy rather than copy and mutate, so AFAIK, we basically need to add copy constructors to solve this problem.

- Jonathan M Davis
August 24, 2013
On 8/24/13, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> The immutable int is changed

Yeah.

> and apparently the same address has
> two different values at the same time!

Apparently, but it's not what happens. The compiler optimizes the call to writeln by substituting 'i' with its value. This would be a safe optimization based on immutability rules, were it not for the postblit bug.
August 24, 2013
On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
> On Friday, 23 August 2013 at 11:40:48 UTC, Namespace wrote:
>> On Friday, 23 August 2013 at 11:33:11 UTC, Andrej Mitrovic wrote:
>>> On Friday, 23 August 2013 at 11:30:01 UTC, deadalnix wrote:
>>>> I see Andrei running away !
>>>
>>> I see an upcoming drinking game at the next dconf. A shot of whiskey anytime anyone mentions allocators. :P
>>
>> Or auto ref. ;)
>
> Or shared.
>
> Or const.
>
> Or scope.
>
> Or Object methods.
>
> There's quite a few unresolved issues!

Or: http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmars-d@puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org
August 24, 2013
On Saturday, 24 August 2013 at 19:15:13 UTC, Namespace wrote:
> On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
>> There's quite a few unresolved issues!
>
> Or: http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmars-d@puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org

That's not a language issue, that's a compiler feature request that does not affect the language semantics at all.

David
August 24, 2013
On Saturday, 24 August 2013 at 20:56:09 UTC, David Nadlinger wrote:
> On Saturday, 24 August 2013 at 19:15:13 UTC, Namespace wrote:
>> On Friday, 23 August 2013 at 17:27:39 UTC, Peter Alexander wrote:
>>> There's quite a few unresolved issues!
>>
>> Or: http://forum.dlang.org/thread/mailman.835.1332024849.4860.digitalmars-d@puremagic.com#post-wyloejdfqjzglqbybpxv:40forum.dlang.org
>
> That's not a language issue, that's a compiler feature request that does not affect the language semantics at all.
>
> David

What's about the probable change of virtual by default -> final by default?
August 24, 2013
On 08/24/2013 12:42 AM, Peter Alexander wrote:
> On Friday, 23 August 2013 at 20:20:21 UTC, Timon Gehr wrote:
>> On 08/23/2013 10:08 PM, Peter Alexander wrote:
>>> On Friday, 23 August 2013 at 20:04:28 UTC, H. S. Teoh wrote:
>>>> What's the problem with const again?
>>>
>>> I'm thinking mainly of const postblit, and the ramifications of solving
>>> that.
>>
>> What problem does const postblit have that a const constructor does
>> not have?
>
> Currently, const postblit completely breaks the type system.
>
> struct Foo
> {
>      this(this) { *p = 2; }
>      int* p;
> }
> ...

That's a mutable postblit, but I see the point.

> void main()
> {
>      import std.stdio;
>      immutable int i = 1;
>      const(Foo) a = const(Foo)(&i);
>      const(Foo) b = a;

I think this line should fail for lack of an appropriately qualified postblit.

>      writeln(a.p, " ", *a.p);
>      writeln(b.p, " ", *b.p);
>      writeln(&i, " ", i);
> }
>
> For me, this gives:
>
> 7FFF5257D418 2
> 7FFF5257D418 2
> 7FFF5257D418 1
>
> The immutable int is changed, and apparently the same address has two
> different values at the same time!
>
> I'm not aware of any way to do this with constructors, but maybe I'm
> just not aware :-)

import std.stdio;

void main(){
    void check(immutable(int)* ptr){
        writeln(ptr," ",*ptr);
    }
    struct S{
        immutable(int) x;
        this(int)const{
            check(&x);
            x=2;
            check(&x);
        }
    }
    auto s = S(0);
}

7FFFAFAA4B80 0
7FFFAFAA4B80 2