On 22 January 2012 18:05, Walter Bright <newshound2@digitalmars.com> wrote:
> On 1/22/2012 9:44 AM, equinox@atw.hu wrote:
>>
>> I noticed I cannot use typedef any longer in D2.
>> Why did it go?
>
>
> typedef turned out to have many difficult issues about when it was a distinct type and when it wasn't.

+1

Walter, what are your views on emitting the names of aliased types to debug?


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 1/23/2012 5:08 AM, Iain Buclaw wrote:
> Walter, what are your views on emitting the names of aliased types to debug?

I don't really have an opinion on it, except that generally when I'm debugging I'm interested in what a type really is, not the layer over it.

Walter:

> I don't really have an opinion on it, except that generally when I'm debugging I'm interested in what a type really is, not the layer over it.

Both are useful to know for the programmer. See in this enhancement request of mine what both Clang and GCC do: http://d.puremagic.com/issues/show_bug.cgi?id=5004

Bye,
bearophile

On Monday, January 23, 2012 10:08:50 Walter Bright wrote:
> On 1/23/2012 5:08 AM, Iain Buclaw wrote:
> > Walter, what are your views on emitting the names of aliased types to debug?
> I don't really have an opinion on it, except that generally when I'm debugging I'm interested in what a type really is, not the layer over it.

I usually want the aliased type. I can look up what the alias is, but I can't know that something is using an alias if the alias is gone.

- Jonathan M Davis

"bcs" <bcs@example.com> wrote in message news:jfhqgv$13f7$1@digitalmars.com...
> On 01/22/2012 10:09 AM, Walter Bright wrote:
>> On 1/22/2012 4:40 AM, Marco Leise wrote:
>>> Or is
>>> this like spaces vs. tabs? 'Cause I'm also a tab user.
>>
>> I struggled with that for years. Not with my own code, the tabs worked fine. The trouble was when collaborating with other people, who insisted on using tab stop settings that were the evil spawn of satan. Hence, collaborated code was always a mess.
>>
>> Like newklear combat toe to toe with the roosskies, the only way to win is to not play.
>
> The only way to win the whitespace war is to change the rules:
>
> My I propose the following modifications to the D lexer:
>
> '''
> White space may consist of:
> - A comment between any two tokens.
> - A single space between tokens that, if adjoined would be a single token.
>
> All other white space (including \n \r \t \v, etc.) is forbidden and a
> lexical error.
> '''
>
> With these additions, all valid D code will be so hard to read that nobody will ever attempt to read it without first running a re-formatter over it and once that is standard practice, everyone will see it in there own preferred style.

Hah! I like it :)

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jfhjd6$lgf$1@digitalmars.com...
> On 1/22/2012 4:40 AM, Marco Leise wrote:
>> Or is
>> this like spaces vs. tabs? 'Cause I'm also a tab user.
>

The dirty rotten spacies can pry the tabs from my cold dead hands ;)

> I struggled with that for years. Not with my own code, the tabs worked fine. The trouble was when collaborating with other people, who insisted on using tab stop settings that were the evil spawn of satan. Hence, collaborated code was always a mess.
>

How is that even *possible*? No matter what a user's tab size is, it's not going to affect anyone else unless they've snuck spaces in there, too.

> Like newklear combat toe to toe with the roosskies, the only way to win is to not play.

In Soviet Russia, the tabstop adjusts YOU!

(Nah, I don't know what the hell I mean by that either...)

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.742.1327344456.16222.digitalmars-d@puremagic.com...
> On Monday, January 23, 2012 10:08:50 Walter Bright wrote:
>> On 1/23/2012 5:08 AM, Iain Buclaw wrote:
>> > Walter, what are your views on emitting the names of aliased types to debug?
>>
>> I don't really have an opinion on it, except that generally when I'm debugging I'm interested in what a type really is, not the layer over it.

That's a pain in the ass for library users. For example, Goldie uses a lot of type sugar so that a nonteminal generated from the rule:

     <Foo> ::= <Bar> ';'

Is usually referred to as type:

     A: Token_myLang!("<Foo>", "<Bar>", ";")

Instead of:

     B: Token_myLang!(
        "<Foo>",
        Token_myLang!(SymbolType.NonTerminal, "<Bar>"),
        Token_myLang!(SymbolType.Terminal, ";") )

     or:

     C: _Token_myLang!("<Foo>", 47); // Rule ID#

The "B" is a rarely-needed unsugared version (which is guaranteed to be unambiguous with other symbols in th grammar). And "C" (or something similar to it) is the true underlying type that's intended purely as an implementation detail - *NOT* for user consumption.

The policy of showing types de-aliased breaks proper encapsulation and just detroys all of the above whenever there's a type error (which is the whole point of having those types in the first place).

>
> I usually want the aliased type.

Same here. I usually find it far more relevent to the code the compiler's referring too.

The current way is like having error messages show mangled names or talking in terms of the generated assembly instructions: It totally breaks out of the proper context and level-of-abstraction.

> I can look up what the alias is, but I can't
> know that something is using an alias if the alias is gone.
>

I hadn't thought of that, that's a good point, too.

On Monday, 23 January 2012 at 18:08:51 UTC, Walter Bright wrote:
> On 1/23/2012 5:08 AM, Iain Buclaw wrote:
>> Walter, what are your views on emitting the names of aliased types to debug?
>
> I don't really have an opinion on it, except that generally when I'm debugging I'm interested in what a type really is, not the layer over it.

While this is D1 I think it applies to D2 as well. Classes can be substituted for packages the same behavior is still observed. And yes I have code that does this [1].


class A { class Foo {} }

class B { class Foo {} }

alias A.Foo AFoo;
alias B.Foo BFoo;

void bar(AFoo f)
{
       BFoo var;
       bar(var);
}

src/foo.d(12): Error: function foo.bar (Foo) does not match parameter types (Foo)
src/foo.d(12): Error: cannot implicitly convert expression (var) of type foo.B.Foo to foo.A.Foo

The first error line is a bit confusing, the second gets it correct. I guess its mostly my fault here, but getting AFoo and BFoo in the first line and then the full print out in the second would be the best for my case at least.

Cheers, Jakob.


[1] https://github.com/Wallbraker/Charged-Miners/blob/master/src/charge/charge.d

On Sun, 22 Jan 2012 23:38:24 -0500, Kagamin <spam@here.lot> wrote:

> On Sunday, 22 January 2012 at 22:17:10 UTC, Marco Leise wrote:
>>> If you ignore type limits, you're asking for trouble. Imagine you have 2 gigs of ram and 3 gig pagefile on 32-bit OS. What is the total size of available memory?
>>
>> I can use up to 4GB of that in the address space of my application - the value range of a uint, qed
>
> With PAE it's possible to access more than that. AFAIK some web-servers do it.

The OS supports it, but not on a single process.  You could achieve the feat with multiple processes.  But then again, nobody cares about PAE anymore, just go 64-bit.

-Steve