Re: Why typedef's shouldn't have been removed :(

[Mehrdad]

(Sorry that wasn't meant to be directed at you, I just happened
to click reply on your post)

On Saturday, 5 May 2012 at 05:25:29 UTC, Maxim Fomin wrote:

On Saturday, 5 May 2012 at 05:02:48 UTC, Mehrdad wrote:
Now it's impossible to figure out whether a ParameterTypeTuple 
contains an HWND versus an HGDIOBJ or whatever...


this should really be fixed...


Features like this:

typedef int type = 5;
type var;
var.init; // is 5

AFAIK are also lost.

Re: GSOC Linker project

[dennis luehring]

Am 04.05.2012 20:26, schrieb Steven Schveighoffer:

On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
  wrote:


 On 5/4/12, foobar  wrote:

 How about augmenting the object format so that libraries would be
 self contained and would not require additional .di files? Is
 this possible optlink by e.g. adding special sections that would
 be otherwise ignored?


 How would you use a library you don't even have the interface to? I
 mean if you can't even look at the API in your editor.. that'd be
 insane.


Ever heard of Java?

-Steve


ever heard about Turbo Pascal (and delphi) got this feature since turbo 
pascal 4 around 1987


and turbo pascal and delphi are extremely fast native compilers without 
any Java, .Net magic

Re: Integer overflow and underflow semantics

[Alex Rønne Petersen]

On 05-05-2012 07:32, Era Scarecrow wrote:

On Saturday, 5 May 2012 at 04:57:48 UTC, Alex Rønne Petersen wrote:

Hi,

I don't think the language really makes it clear whether overflows and
underflows are well-defined. Do we guarantee that for any integral
type T, T.max + 1 == T.min and T.min - 1 == T.max?

This is relevant in particular for GDC and LDC since they target a lot
of weird architectures.


Any systems that implement a carry flag likely works exactly like that.
Carry flag is set or cleared after a math operation, allowing you to
extend the size of your integer any level you want, like in oh the 6502?

Might look something like this: Been a while but you should get the idea

clc ;clear carry
loop_here:
mov ax, [bx]
adc [dx], ax
inc bx
inc dx
dec cx
cmp cx, 0
jne loop_here

;if carry after this point then...
jc overflow_warning



Right, but the question was whether the language guarantees what I 
described. C and C++ don't, and IMO, we should strive to fix that.


--
- Alex

Re: GSOC Linker project

[dennis luehring]

Am 05.05.2012 09:06, schrieb dennis luehring:

Am 04.05.2012 20:26, schrieb Steven Schveighoffer:

 On Fri, 04 May 2012 13:54:38 -0400, Andrej Mitrovic
wrote:


  On 5/4/12, foobar   wrote:

  How about augmenting the object format so that libraries would be
  self contained and would not require additional .di files? Is
  this possible optlink by e.g. adding special sections that would
  be otherwise ignored?


  How would you use a library you don't even have the interface to? I
  mean if you can't even look at the API in your editor.. that'd be
  insane.


 Ever heard of Java?

 -Steve


ever heard about Turbo Pascal (and delphi) got this feature since turbo
pascal 4 around 1987

and turbo pascal and delphi are extremely fast native compilers without
any Java, .Net magic


an more up-to-date example can be seen using the freepascal compiler and
its ppdump tool: http://www.freepascal.org/tools/ppudump.var

and turbo pascal gots even since 1987 a very good package system like a 
Java Jar file - you can just integrate compiled pascal sources (.pas -> 
.tpu) into something called .tpl file (turbo pascal library)


the freepascal compiler got something similar called .ppl

these "technologies" are damn good and invented so long before - but 
sometimes totaly unknown to all the obj-file-linker-guys

Re: Integer overflow and underflow semantics

[Era Scarecrow]

On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen 
wrote:


Right, but the question was whether the language guarantees 
what I described. C and C++ don't, and IMO, we should strive to 
fix that.


 I can't see why it wouldn't, unless the compiler adds in checks 
and changes it's behavior or the assembler does it's own quirky 
magic. The bit patterns of how they end up are pretty fixed, it's 
just how we interpret them.


 I know before when i needed to know if it overflowed and 
simulated the carry flag, i ended up using a larger type of int. 
(This was for a custom multiple precision unsigned ints)




 Of course now that I think about it, if anything ends up using 
MMX for it's registers, the rules do change a little. MMX don't 
overflow if I remember right, they just cap/truncate to the 
Max/Min. Since it's intended more for multimedia... If the 
compiler uses those, I can't tell you what would happen.

Re: Integer overflow and underflow semantics

[Alex Rønne Petersen]

On 05-05-2012 10:23, Era Scarecrow wrote:

On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:


Right, but the question was whether the language guarantees what I
described. C and C++ don't, and IMO, we should strive to fix that.


I can't see why it wouldn't, unless the compiler adds in checks and
changes it's behavior or the assembler does it's own quirky magic. The
bit patterns of how they end up are pretty fixed, it's just how we
interpret them.


It all depends. GCC (and thus GDC) can target very exotic architectures 
where any assumptions may not, for whatever reason, hold true. This is a 
language design issue more than it's a "how does architecture X or 
compiler Y work" issue.


An interesting problem with undefined behavior for integer overflow and 
underflow in C/C++ is that optimizers are basically free to do anything 
with regards to them, and often do whatever is more convenient for them.




I know before when i needed to know if it overflowed and simulated the
carry flag, i ended up using a larger type of int. (This was for a
custom multiple precision unsigned ints)



Of course now that I think about it, if anything ends up using MMX for
it's registers, the rules do change a little. MMX don't overflow if I
remember right, they just cap/truncate to the Max/Min. Since it's
intended more for multimedia... If the compiler uses those, I can't tell
you what would happen.


Right, but it's not so much about what *would* happen as much as it is 
about what *should* happen. ;)


--
- Alex

Re: GSOC Linker project

[Jacob Carlborg]

On 2012-05-05 00:39, H. S. Teoh wrote:


It's often impossible to debug something if you don't get to see what
the compiler sees. I suppose you could argue that leaving out function
bodies and stuff amounts to the same thing, but at least the language's
interface for a function is the function's signature. When you have a
.di file, you're guaranteed that all public declarations are there, and
you can see exactly what they are. Of course, IF ddoc can be guaranteed
to produce exactly what's in a .di file, then I concede that it is
sufficient this purpose.


If the compiler can extract the .di files from an object file so can 
other tools. I don't see the problem.


--
/Jacob Carlborg

Re: Return by 'ref' problems...

[Manu]

On 5 May 2012 09:09, Artur Skawina  wrote:

> On 05/05/12 01:32, Manu wrote:
> > On 4 May 2012 21:51, Artur Skawina  art.08...@gmail.com>> wrote:
> >
> > On 05/04/12 15:57, Manu wrote:
> > > Yeah I really hate this too. I'd like to see const(T) strictly
> enforced, considering the potential for ambiguity in other situations.
> > >
> > > But I'm still stuck! :(
> > > How can I do what I need to do?
> >
> > If 'auto' is not an option:
> >
> >   alias ref const(S) function() FT;
> >   FT fp;
> >
> > (it's needed for things like 'extern (C)' too)
> >
> >
> > Huzzah! This is indeed the solution! I haven't seen another solution
> that works. now I just need to make sure I generate a unique name for the
> alias...
> >
> > I don't think this is needed for extern (C), I declare extern (C)
> function pointers all the time without any trick..?
>
>void f(extern (C) int function(double) a);
>

Hmm, actually, this makes me question my code...

struct Thing
{
  extern (C) void function() funcPtr;
}

Have I declared a pointer to an extern(C) function, or have I declared an
extern(C) variable funcPtr that is a regular D-call function?
extern(C) variables only really make sense in the global scope, where they
would have C-style name mangling applied...

Re: Integer overflow and underflow semantics

[Manu]

On 5 May 2012 11:42, Alex Rønne Petersen  wrote:

> On 05-05-2012 10:23, Era Scarecrow wrote:
>
>> On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:
>>
>>  Right, but the question was whether the language guarantees what I
>>> described. C and C++ don't, and IMO, we should strive to fix that.
>>>
>>
>> I can't see why it wouldn't, unless the compiler adds in checks and
>> changes it's behavior or the assembler does it's own quirky magic. The
>> bit patterns of how they end up are pretty fixed, it's just how we
>> interpret them.
>>
>
> It all depends. GCC (and thus GDC) can target very exotic architectures
> where any assumptions may not, for whatever reason, hold true. This is a
> language design issue more than it's a "how does architecture X or compiler
> Y work" issue.
>
> An interesting problem with undefined behavior for integer overflow and
> underflow in C/C++ is that optimizers are basically free to do anything
> with regards to them, and often do whatever is more convenient for them.


With regard to code-gen on such colourful architectures, would stating a
defined behaviour for overflow/underflow affect the common case where an
over/underflow did not occur?
Short of an architecture that causes hardware exception on over/underflow,
I suspect that it would interfere with the common case (additional code
generated around every add/sub/etc to handle the overflow behaviour), and
on such an architecture, every single numerical integer operation would
become inefficient.

I believe this is why C doesn't define the behaviour, because C is still
effectively a macro language, and shouldn't produce 'unexpected'
inefficient code. ('unexpected' from the perspective of the architecture
you're targeting)

I would personally rather see it remain undefined like C, but with
convention approved by common/conventional architectures where cross
platform porting is likely to occur.

Re: Integer overflow and underflow semantics

[Alex Rønne Petersen]

On 05-05-2012 12:25, Manu wrote:

On 5 May 2012 11:42, Alex Rønne Petersen mailto:xtzgzo...@gmail.com>> wrote:

On 05-05-2012 10 :23, Era Scarecrow wrote:

On Saturday, 5 May 2012 at 07:10:28 UTC, Alex Rønne Petersen wrote:

Right, but the question was whether the language guarantees
what I
described. C and C++ don't, and IMO, we should strive to fix
that.


I can't see why it wouldn't, unless the compiler adds in checks and
changes it's behavior or the assembler does it's own quirky
magic. The
bit patterns of how they end up are pretty fixed, it's just how we
interpret them.


It all depends. GCC (and thus GDC) can target very exotic
architectures where any assumptions may not, for whatever reason,
hold true. This is a language design issue more than it's a "how
does architecture X or compiler Y work" issue.

An interesting problem with undefined behavior for integer overflow
and underflow in C/C++ is that optimizers are basically free to do
anything with regards to them, and often do whatever is more
convenient for them.


With regard to code-gen on such colourful architectures, would stating a
defined behaviour for overflow/underflow affect the common case where an
over/underflow did not occur?
Short of an architecture that causes hardware exception on
over/underflow, I suspect that it would interfere with the common case
(additional code generated around every add/sub/etc to handle the
overflow behaviour), and on such an architecture, every single numerical
integer operation would become inefficient.


I don't know of a single architecture (out of the ones on 
dlang.org/version.html and many others) that doesn't signal 
overflow/underflow somehow (or obey the rules I described in the OP).




I believe this is why C doesn't define the behaviour, because C is still
effectively a macro language, and shouldn't produce 'unexpected'
inefficient code. ('unexpected' from the perspective of the architecture
you're targeting)


Right, but C was designed many, many years ago. :)



I would personally rather see it remain undefined like C, but with
convention approved by common/conventional architectures where cross
platform porting is likely to occur.


Do a grep for "\.min" and "\.max" in Phobos and you'll notice a lot of 
places actually depend on the current x86 behavior (wrapping on overflow 
and underflow). I don't think we can afford to make the same mistake C 
and C++ did.


While I did say that this is a language design issue, it's also a matter 
of pragmatism - does any real world architecture that D could possibly 
target actually *not* obey the aforementioned rules? I don't know of any 
that doesn't.


--
- Alex

Re: Integer overflow and underflow semantics

[bearophile]

Alex Rønne Petersen:

I don't think the language really makes it clear whether 
overflows and underflows are well-defined. Do we guarantee that 
for any integral type T, T.max + 1 == T.min and T.min - 1 == 
T.max?


This is relevant in particular for GDC and LDC since they 
target a lot of weird architectures.


In a good system language I'd like to see something better than 
what's present in C#. So I'd like the language to offer the 
programmer the choice of 3 or 4 different semantics in integral 
operations:


1) A shared standard semantics that overflows, as in Java;
2) A semantics that overflows, that adapts to the fastest 
available on the CPU, as in C;
3) Shared standard overflows with unsigned values and run-time 
errors when a signed value overflows (or goes out of its range).
4) Run-time errors when every signed or unsigned value overflows 
(or goes out of its range), as in Ada.


Bye,
bearophile

Re: Why typedef's shouldn't have been removed :(

[bearophile]

Mehrdad:
Now it's impossible to figure out whether a ParameterTypeTuple 
contains an HWND versus an HGDIOBJ or whatever...


this should really be fixed...


typedef is a quite useful feature, but the one present in D was 
unsound/broken, especially in presence of OOP. Fixing language 
features is hard (people didn't seem to understand that typedef 
is not meant to be used with classes), once their semantics is 
defined, it's quite hard to fix it. But adding features to 
D/Phobos is much simpler. So once there is a clear and sound 
design for what this feature has to do and its semantics, I 
expect to see in D a way to do the same things. Currently the 
Typedef in Phobos is more broken than the built-in typedef. Here 
the Ada language is a good reference to copy from. So the idea of 
removing typedef was good iff we eventually have something good 
to replace it.


Bye,
bearophile

Re: Integer overflow and underflow semantics

[Alex Rønne Petersen]

On 05-05-2012 13:06, bearophile wrote:

Alex Rønne Petersen:


I don't think the language really makes it clear whether overflows and
underflows are well-defined. Do we guarantee that for any integral
type T, T.max + 1 == T.min and T.min - 1 == T.max?

This is relevant in particular for GDC and LDC since they target a lot
of weird architectures.


In a good system language I'd like to see something better than what's
present in C#. So I'd like the language to offer the programmer the
choice of 3 or 4 different semantics in integral operations:

1) A shared standard semantics that overflows, as in Java;
2) A semantics that overflows, that adapts to the fastest available on
the CPU, as in C;
3) Shared standard overflows with unsigned values and run-time errors
when a signed value overflows (or goes out of its range).
4) Run-time errors when every signed or unsigned value overflows (or
goes out of its range), as in Ada.

Bye,
bearophile


Good point. The wrapping rule described in my OP should be the default 
IMO. Then perhaps the other modes could be activated with an @attribute 
of sorts?


--
- Alex

Static versus dynamic binding of in contracts again - trying to set things straight

[Stewart Gordon]

http://d.puremagic.com/issues/show_bug.cgi?id=6857

It seems we can't all be agreed on how it should be.


It seems part of the problem is that there are two views on the essence of an in contract 
in an OOP context:


(a) it is part of the API of the class and, as such, a specification to which any user of 
the class must conform


(b) it is a means of verifying that the target object can handle the input being passed 
into it


Current D takes view (b), by checking the in contract according to the actual class of the 
object - dynamic binding.  Several of us (myself included) have argued on the basis of 
view (a), that it should be checked according to the compile-time type of the object 
reference - static binding.



So far, there have been arguments both ways.

Arguments in favour of static binding:

s1. A user of a class A, in the general case, doesn't know whether something of type A is 
a plain A or something of some subclass of A.  This is part of the OO principle of 
encapsulation.  As such, it doesn't make sense for the class user to rely on the widened 
preconditions in subclasses it doesn't know about.  (But see d3.)


s2. As such, it helps detect more bugs in code that uses a class of which programmers are 
likely to create subclasses.


s3. Obeys the Liskov substitution principle.

s4. Consistency with the inability of a base class user to call methods that exist only in 
a derived class.  If a subclass introduces a new method, that new method doesn't exist 
from the base class's point of view.  In the same way, if a subclass introduces new legal 
arguments to a method, those new legal arguments don't exist from the base class's point 
of view.



Arguments in favour of dynamic binding:

d1. It's part of how overriding is meant to work, per OO principles.  A method call is 
resolved through the virtual method table of the object's actual class.  (But this is 
based on the premise that an in contract is just another method.  Which it isn't.  An in 
contract is a specification of what is a legal call of a method, quite a different concept 
from the method itself, which provides functionality to the class.)


d2. Bertrand Meyer's book explains why this is the way in which it must work.  (But the 
truth of this claim has been challenged.)


d3. It allows inputs not allowed by the base class contract to be passed in under 
controlled conditions - conditions in which some other method is defined from whose return 
value the legality of some input can be determined.  Example provided by Walter himself:


class A {
void foo(int x) in { assert(x > 0); } body {}
int bar() { return 1; }
}

class B : A {
void foo(int x) in { assert(x > -2); } body {}
int bar() { return -1; }
}

void fizzbuzz(A a) {
a.foo(bar());
}

(While I can see this being useful, it doesn't change the fact that fizzbuzz is asking the 
class A, not the class B, for the method foo.  And the A.foo contract could just as well 
have been written

in { assert(x > 0 || x == bar()); }
thereby causing the call to conform according to view (a) above, hence (d4 aside) enabling 
static binding to be considered without this getting in the way.)


d4. Now that D behaves in this way, there is going to be code out there that does 
something like the example in d3.  Changing to static binding would break this code. (This 
seems the one argument for dynamic binding that I'm inclined to agree with.)



deadalnix has pointed out that design of OOP doesn't say anything about contracts.  In 
which case any claim that the whole OOP paradigm takes either view (a) or view (b) is 
nonsense.


Maybe what's needed is a clarification in the spec of which concept of an in contract 
(view (a), view (b) or something else) D intends to implement.


If (a), then we need static binding.  But how do we deal with the code breakage pointed 
out in d4?


If (b), then we need to stick with the current dynamic binding.  And people taking view 
(a) will still complain about it.  But a clear spec on the issue would at least be 
something to which people complaining about (a) can be pointed.


Stewart.

Re: GSOC Linker project

[foobar]

On Friday, 4 May 2012 at 22:38:27 UTC, H. S. Teoh wrote:

On Sat, May 05, 2012 at 12:07:16AM +0200, foobar wrote:

On Friday, 4 May 2012 at 21:11:22 UTC, H. S. Teoh wrote:
>Exactly. And while we're at it, *really* strip unnecessary 
>stuff from
>.di files, like function bodies, template bodies, etc.. That 
>stuff is
>required by the compiler, not the user, so stick that in the 
>object
>files and let the compiler deal with it. The .di file should 
>be ONLY
>what's needed for the user to understand how to use the 
>library.

>
>
>T

You contradict yourself.
The purpose of di files *is* to provide the compiler the 
required
info to use the binary object/library. If you want human 
readable

docs we already have DDoc (and other 3rd party tools) for that.
If you don't like the default HTML output (I can't fathom why) 
you
can easily define appropriate macros for other output types 
such as

TeX (and PDF via external converter), text based, etc..


HTML is a stupid format, and ddoc output is not very navigable, 
but
that's beside the point. I prefer to be reading actual code to 
be 100%
sure that ddoc isn't leaving out some stuff that I should know 
about.
All it takes is for somebody to leave out a doc comment and a 
particular
declaration becomes invisible. (For example, std.uni was next 
to useless
before I discovered that it actually had functions that I 
needed, but
they didn't show up in dlang.org 'cos somebody failed to write 
doc
comments for them.) I've seen too many commercial projects to 
believe
for a moment that documentation is ever up-to-date. It depends 
on the
library authors to provide ddoc output formats in a sane, 
usable format.
Whereas if the compiler had a standardized, uniform, 
understandable

format in well-known code syntax, that's a lot more dependable.

It's often impossible to debug something if you don't get to 
see what
the compiler sees. I suppose you could argue that leaving out 
function
bodies and stuff amounts to the same thing, but at least the 
language's
interface for a function is the function's signature. When you 
have a
.di file, you're guaranteed that all public declarations are 
there, and
you can see exactly what they are. Of course, IF ddoc can be 
guaranteed
to produce exactly what's in a .di file, then I concede that it 
is

sufficient this purpose.


T


This all amounts to the issues you have with the current 
implementation of DDoc which I agree needs more work.

The solution then is to fix/enhance DDoc.
Doxygen for instance has a setting to output all declarations 
whether documented or not, thus addressing your main point.


The projects you speak of I assume are written in C/C++? Those 
tend to have poor documentation precisely because people assume 
the header files are enough.
C/C++ requires you to install a 3rd party doc tool and learn that 
tool's doc syntax - effort that people are too lazy to invest.


In the Java world the syntax is standardized, the tool comes 
bundled with the compiler, all tools speak it and IDEs will even 
insert empty doc comment for you automatically. Frankly it takes 
effort to *not* document your code in this setting.
D provides DDoc precisely because it strives to provide the same 
doc friendly setting as Java.

Re: GSOC Linker project

[Adrian]

Am 04.05.2012 19:54, schrieb Andrej Mitrovic:

On 5/4/12, foobar  wrote:

How about augmenting the object format so that libraries would be
self contained and would not require additional .di files? Is
this possible optlink by e.g. adding special sections that would
be otherwise ignored?


How would you use a library you don't even have the interface to? I
mean if you can't even look at the API in your editor.. that'd be
insane.


Delphi does this since ages!

Re: Why typedef's shouldn't have been removed :(

[Michel Fortin]

On 2012-05-05 05:02:44 +, "Mehrdad"  said:

Now it's impossible to figure out whether a ParameterTypeTuple contains 
an HWND versus an HGDIOBJ or whatever...


this should really be fixed...


It should be fixed indeed. Perhaps HWND should be defined more like this:

struct HWND { void *handle; }

Or if you want it to implement some kind of inheritance scheme:

struct HANDLE { void *ptr; }
struct HWND { HANDLE handle; alias handle this; }

That's still a lot better than typedef since you can control what 
operations are allowed on the type. For instance, you can't multiply 
two handles with the struct definition, with typedef you could.


My only fear is that this might not work play well with the C calling 
convention (or Window's in this case). If that's the case, then it's a 
good argument for having a separate language construct.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Why typedef's shouldn't have been removed :(

[Gor Gyolchanyan]

mixin template TypeDef(Type, string name, Type init)
{
mixin(`struct `~name~` { public alias _impl this; private Type
_impl = init; };`);
}

unittest
{
mixin TypeDef!(int, `MyInt`, 5);

MyInt mi;

assert(typeid(myInt) != typeid(int));
assert(mi == 5);
}

On Sat, May 5, 2012 at 3:09 PM, bearophile  wrote:
> Mehrdad:
>
>> Now it's impossible to figure out whether a ParameterTypeTuple contains an
>> HWND versus an HGDIOBJ or whatever...
>>
>> this should really be fixed...
>
>
> typedef is a quite useful feature, but the one present in D was
> unsound/broken, especially in presence of OOP. Fixing language features is
> hard (people didn't seem to understand that typedef is not meant to be used
> with classes), once their semantics is defined, it's quite hard to fix it.
> But adding features to D/Phobos is much simpler. So once there is a clear
> and sound design for what this feature has to do and its semantics, I expect
> to see in D a way to do the same things. Currently the Typedef in Phobos is
> more broken than the built-in typedef. Here the Ada language is a good
> reference to copy from. So the idea of removing typedef was good iff we
> eventually have something good to replace it.
>
> Bye,
> bearophile



-- 
Bye,
Gor Gyolchanyan.

Re: Static versus dynamic binding of in contracts again - trying to set things straight

[deadalnix]

Le 05/05/2012 14:46, Stewart Gordon a écrit :

d2. Bertrand Meyer's book explains why this is the way in which it must
work. (But the truth of this claim has been challenged.)



http://se.ethz.ch/~meyer/publications/computer/contract.pdf

The extract of the book covering that specific point is available here. 
Meyer explain HOW thing work and then how this behavior provide some 
benefices. Careful reading of the passage show that BOTH behavior we are 
talking here provide such benefices. This reading isn't going to 
conclude the discussion.


Additionally, Meyer state that the in contract is a constraint for the 
caller. This is an argument in favor of view (a).


I do think EIFFEL implementation provide less benefices than the 
proposed new behavior.


I plan to contact Meyer himself to discuss the subject.


d3. It allows inputs not allowed by the base class contract to be passed
in under controlled conditions - conditions in which some other method
is defined from whose return value the legality of some input can be
determined. Example provided by Walter himself:

class A {
void foo(int x) in { assert(x > 0); } body {}
int bar() { return 1; }
}

class B : A {
void foo(int x) in { assert(x > -2); } body {}
int bar() { return -1; }
}

void fizzbuzz(A a) {
a.foo(bar());
}



The fizzbuzz function here is flawed. bar doesn't provide any guarantee 
on its return value. foo expect fizzbuzz to provide a parameter with 
certain properties.


fizzbuzz is unable to ensure it is doing its part of the contract. 
Correct alternative are either :
 - adding an out contract on A.bar to ensure that the value returned is 
above 0 and so can be safely passed to foo. This solution make B.bar 
invalid, but fizzbuzz now is able to honor its part f the contract.
 - adding a new condition to A.foo's in contract to accept bar's return 
value. This also require that A.bar is made pure.
 - fizzbuzz is rewritten to ensure that the value returned by bar is 
valid according to foo's contract. The only contract that fizzbuzz knows 
about is A.foo and so it should apply criteria on that one. It means 
that B.bar's return valus will be discarded by fizzbuzz and it will not 
call a.foo in case of a being an instance of B.



d4. Now that D behaves in this way, there is going to be code out there
that does something like the example in d3. Changing to static binding
would break this code. (This seems the one argument for dynamic binding
that I'm inclined to agree with.)



As seen above, cases where things risk to break is exactly what we want. 
Contract is supposed to break bad code ASAP.



deadalnix has pointed out that design of OOP doesn't say anything about
contracts. In which case any claim that the whole OOP paradigm takes
either view (a) or view (b) is nonsense.



After some thinking, I want to make a stronger point.

A good guideline in OOP is to hide implementation. A contract is an 
agreement between the caller and the callee, and so, mustn't be hidden 
in any way. It certainly exclude the contract as being part of the 
implementation.


view (b) imply that the in contract is part of the implementation (ie, 
can the provided implementation handle that input or not). OOP don't say 
anything about contracts, but view (b) is breaking encapsulation, and 
encapsulation is an OOP principle.



Maybe what's needed is a clarification in the spec of which concept of
an in contract (view (a), view (b) or something else) D intends to
implement.



The spec is very explicit on that point. view (b) is the specified one. 
But I think it is an error.



If (a), then we need static binding. But how do we deal with the code
breakage pointed out in d4?



Breaking flawed code is a benefit, not an issue.

Re: Static versus dynamic binding of in contracts again - trying to set things straight

[Stewart Gordon]

On 05/05/2012 15:07, deadalnix wrote:


http://se.ethz.ch/~meyer/publications/computer/contract.pdf

The extract of the book covering that specific point is available
here.  Meyer explain HOW thing work and then how this behavior
provide some benefices.  Careful reading of the passage show that
BOTH behavior we are talking here provide such benefices.  This
reading isn't going to conclude the discussion.


Exactly.  Moreover, I noticed that you quoted portions of it on BZ, including
"Yet, because of dynamic binding, A may subcontract the execution of r to B, and it is B’s 
contract that will be applied."


There seems to be an unfounded assumption here: that a compiler will necessarily implement 
contract checking as part of the method body.  Really, there's no explanation of "it is 
B’s contract that will be applied" there.  Contract checking happens before and is 
conceptually separate from method execution.



Additionally, Meyer state that the in contract is a constraint for
the caller.  This is an argument in favor of view (a).


That is indeed what it seems to be saying.  Among other things:
"A precondition violation indicates a bug in the client (caller). The caller did not 
observe the conditions imposed on correct calls."




The fizzbuzz function here is flawed.  bar doesn't provide any
guarantee on its return value.  foo expect fizzbuzz to provide a
parameter with certain properties.


Taken the words out of my mouth there.  fizzbuzz is not using the class B.  It is using 
the class A.  Going by view (a), since foo(-1) is not a legal call according to A's API - 
and moreover, A's API makes no guarantees that foo(bar()) generally will be a legal call - 
the code is incorrect.


I agree with the rest of your points as well.



Maybe what's needed is a clarification in the spec of which
concept of an in contract (view (a), view (b) or something else) D
intends to implement.


The spec is very explicit on that point.  view (b) is the specified
one.  But I think it is an error.



Where is it addressed?

Stewart.

Re: Broken newsgroup threading (was: Re: An observation)

[H. S. Teoh]

On Sat, May 05, 2012 at 01:00:40AM -0400, Jeff Nowakowski wrote:
> On 05/03/2012 06:07 AM, Tobias Pankrath wrote:
> >
> >Does the D newsgroup have broken threading in mutt? In my client
> >threading breaks often because some answers starts new thread etc.
> >makes the hole thing useless.
> 
> The broken threading is caused by the Mailman newsgroup to mailing
> list gateway, as described in this post:
> http://forum.dlang.org/post/akftpzpkwuoqmfzij...@dfeed.kimsufi.thecybershadow.net

Ahhh, that explains so much. Thanks for pointing this out!


> I was looking briefly at this issue recently, as it was getting
> annoying to follow the large threads in my newsreader, and it seems to
> me that the Mailman stance of changing the Message-ID is wrong.
[...]
> I found two Mailman bug reports with patches regarding this issue:
> 
> https://bugs.launchpad.net/mailman/+bug/266263
> https://bugs.launchpad.net/mailman/+bug/496233
> 
> I may or may not follow up on this with the Mailman folks. If
> somebody else wants to feel free.

Is there any chance we can apply these patches to the D forums? Or are
we stuck with a default Mailman installation?


T

-- 
It always amuses me that Windows has a Safe Mode during bootup. Does
that mean that Windows is normally unsafe?

Re: GSOC Linker project

[H. S. Teoh]

On Fri, May 04, 2012 at 02:39:00PM -0700, Adam Wilson wrote:
> On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh
>  wrote:
[...]
> >Exactly. And while we're at it, *really* strip unnecessary stuff from
> >.di files, like function bodies, template bodies, etc.. That stuff is
> >required by the compiler, not the user, so stick that in the object
> >files and let the compiler deal with it. The .di file should be ONLY
> >what's needed for the user to understand how to use the library.
[...]
> I've written code to do this, but apparently it breaks Phobos in the
> autotester. I can't get it to break Phobos on my local machine so I'm
> at a loss as how to fix it. Maybe you can help? The code is here:
> https://github.com/LightBender/dmd.git
[...]

Sorry for taking so long to respond, been busy. Got some time this
morning to cloned your repo and built dmd, then rebuilt druntime and
phobos, and got this error from phobos:

../druntime/import/core/sys/posix/sys/select.di(25): function declaration 
without return type. (Note that constructors are always named 'this')
../druntime/import/core/sys/posix/sys/select.di(25): no identifier for 
declarator __FDELT(int d)
../druntime/import/core/sys/posix/sys/select.di(27): function declaration 
without return type. (Note that constructors are always named 'this')
../druntime/import/core/sys/posix/sys/select.di(27): no identifier for 
declarator __FDMASK(int d)
make[1]: *** [generated/linux/release/32/libphobos2.a] Error 1
make: *** [release] Error 2

Looks like the bug only triggers when you rebuild druntime before
rebuilding phobos. Hope this helps. Let me know if you want me to test
anything else.


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

What should array() return for const/immutable ElementTypes?

[David Nadlinger]

The title says it all – currently, std.array.array() is broken 
for (some) ranges of const/immutable elements. Fixing it is not 
hard, but the question is: Should it always return an array of 
(head-)mutable elements (since it allocates a copy anyway), or 
should it preserve constness of the element type?


The latter is maybe be the more »consistent« behavior, as the 
return type would always just be ElementType!Range[], but has the 
disadvantage that if you actually wanted to construct a mutable 
array from an immutable range, you'd have to cast away immutable 
(with unclear semantics), whereas getting an immutable array with 
the first implementation would just require assumeUnique() (for 
most ranges, array() is not going to be strongly pure).


I have a fix ready, but will hold back the pull request until it 
is clear which semantics we want.


Thanks,
David

Re: GSOC Linker project

[H. S. Teoh]

On Sat, May 05, 2012 at 09:51:40AM -0700, H. S. Teoh wrote:
> On Fri, May 04, 2012 at 02:39:00PM -0700, Adam Wilson wrote:
> > On Fri, 04 May 2012 14:12:16 -0700, H. S. Teoh
> >  wrote:
> [...]
> > >Exactly. And while we're at it, *really* strip unnecessary stuff from
> > >.di files, like function bodies, template bodies, etc.. That stuff is
> > >required by the compiler, not the user, so stick that in the object
> > >files and let the compiler deal with it. The .di file should be ONLY
> > >what's needed for the user to understand how to use the library.
> [...]
> > I've written code to do this, but apparently it breaks Phobos in the
> > autotester. I can't get it to break Phobos on my local machine so I'm
> > at a loss as how to fix it. Maybe you can help? The code is here:
> > https://github.com/LightBender/dmd.git
> [...]
> 
> Sorry for taking so long to respond, been busy. Got some time this
> morning to cloned your repo and built dmd, then rebuilt druntime and
> phobos, and got this error from phobos:
> 
> ../druntime/import/core/sys/posix/sys/select.di(25): function declaration 
> without return type. (Note that constructors are always named 'this')
> ../druntime/import/core/sys/posix/sys/select.di(25): no identifier for 
> declarator __FDELT(int d)
> ../druntime/import/core/sys/posix/sys/select.di(27): function declaration 
> without return type. (Note that constructors are always named 'this')
> ../druntime/import/core/sys/posix/sys/select.di(27): no identifier for 
> declarator __FDMASK(int d)
> make[1]: *** [generated/linux/release/32/libphobos2.a] Error 1
> make: *** [release] Error 2
[...]

Oh, and here's the snippet from the offending file
(core/sys/posix/sys/select.di):

--SNIP--
private 
{
alias c_long __fd_mask;
enum uint __NFDBITS = 8 * __fd_mask.sizeof;
extern (D) auto __FDELT(int d); // this is line 
25

extern (D) auto __FDMASK(int d);// this is line 
27

}
--SNIP--

Looks like the problem is caused by the auto, perhaps?


T

-- 
Lottery: tax on the stupid. -- Slashdotter

[Feature Request] Adding to D lang "set" built-in

[bioinfornatics]

Dear, i hope i will got some answer from druntime/phobos dev .
A set is an array of unique element:
>>> set( 1, 5, 7, 1, 7)
give this array => [1, 5, 7]

Currently in D the hack it is to use an associative array with any
value.
byte[size_t] a = [ 1:0, 5:0, 7:0, 1:0, 7:0 ];

then it is easy to have a set in D just add a syntax or a built-in where
use associative array without using value.

I hope really this little feature and seem really easy to add


thanks a lot for your great works

Re: [Feature Request] Adding to D lang "set" built-in

[Gor Gyolchanyan]

I think a much more realistic suggestion would be to add it to phobos
as a struct, which wraps this no-value AA solution.

On Sat, May 5, 2012 at 9:14 PM, bioinfornatics
 wrote:
> Dear, i hope i will got some answer from druntime/phobos dev .
> A set is an array of unique element:
 set( 1, 5, 7, 1, 7)
> give this array => [1, 5, 7]
>
> Currently in D the hack it is to use an associative array with any
> value.
> byte[size_t] a = [ 1:0, 5:0, 7:0, 1:0, 7:0 ];
>
> then it is easy to have a set in D just add a syntax or a built-in where
> use associative array without using value.
>
> I hope really this little feature and seem really easy to add
>
>
> thanks a lot for your great works
>



-- 
Bye,
Gor Gyolchanyan.

Re: What should array() return for const/immutable ElementTypes?

[bearophile]

David Nadlinger:
Should it always return an array of (head-)mutable elements 
(since it allocates a copy anyway), or should it preserve 
constness of the element type?


Ideally the most useful result is a mutable one that is 
implicitly castable to immutable if the mapping function is pure. 
But I don't know if this is always possible.


Bye,
bearophile

Re: [Feature Request] Adding to D lang "set" built-in

[Chris Cain]

There's a few ways to implement your own Sets right now, if 
needed. You found one way (using the built in AAs), but that's 
not all.


* You could use Array!bool (which efficiently stores bools) to 
store whether integers are in or out of your set.
* You can use std.container's redBlackTree to make a set which 
would work better if your items are objects or you're dealing 
with a sparse array.


There's probably a few other extremely simple methods, but those 
are the two I had on the top of my head. I'm not really sure 
having a particular "Set" in the library would be all that 
useful. Generally, if I want a set, I have a particular idea of 
how one should be implemented for my particular data.

Re: Why typedef's shouldn't have been removed :(

[Mehrdad]

How do you fix it for size_t and uint, etc.?

On Saturday, 5 May 2012 at 13:01:08 UTC, Michel Fortin wrote:
On 2012-05-05 05:02:44 +, "Mehrdad"  
said:


Now it's impossible to figure out whether a ParameterTypeTuple 
contains an HWND versus an HGDIOBJ or whatever...


this should really be fixed...


It should be fixed indeed. Perhaps HWND should be defined more 
like this:


struct HWND { void *handle; }

Or if you want it to implement some kind of inheritance scheme:

struct HANDLE { void *ptr; }
struct HWND { HANDLE handle; alias handle this; }

That's still a lot better than typedef since you can control 
what operations are allowed on the type. For instance, you 
can't multiply two handles with the struct definition, with 
typedef you could.


My only fear is that this might not work play well with the C 
calling convention (or Window's in this case). If that's the 
case, then it's a good argument for having a separate language 
construct.

Re: Why typedef's shouldn't have been removed :(

[Gor Gyolchanyan]

See my version.

On Sat, May 5, 2012 at 10:20 PM, Mehrdad  wrote:
> How do you fix it for size_t and uint, etc.?
>
>
> On Saturday, 5 May 2012 at 13:01:08 UTC, Michel Fortin wrote:
>>
>> On 2012-05-05 05:02:44 +, "Mehrdad"  said:
>>
>>> Now it's impossible to figure out whether a ParameterTypeTuple contains
>>> an HWND versus an HGDIOBJ or whatever...
>>>
>>> this should really be fixed...
>>
>>
>> It should be fixed indeed. Perhaps HWND should be defined more like this:
>>
>>        struct HWND { void *handle; }
>>
>> Or if you want it to implement some kind of inheritance scheme:
>>
>>        struct HANDLE { void *ptr; }
>>        struct HWND { HANDLE handle; alias handle this; }
>>
>> That's still a lot better than typedef since you can control what
>> operations are allowed on the type. For instance, you can't multiply two
>> handles with the struct definition, with typedef you could.
>>
>> My only fear is that this might not work play well with the C calling
>> convention (or Window's in this case). If that's the case, then it's a good
>> argument for having a separate language construct.
>
>
>



-- 
Bye,
Gor Gyolchanyan.

Re: Why typedef's shouldn't have been removed :(

[Mehrdad]

The one with TypeDef?

That's not how it's defined though.

On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote:

See my version.

Re: Why typedef's shouldn't have been removed :(

[Gor Gyolchanyan]

The effect is the same. You have a new type with a new init, that
behaves the same way.

On Sat, May 5, 2012 at 10:38 PM, Mehrdad  wrote:
> The one with TypeDef?
>
> That's not how it's defined though.
>
> On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote:
>>
>> See my version.



-- 
Bye,
Gor Gyolchanyan.

Re: What should array() return for const/immutable ElementTypes?

[David Nadlinger]

On Saturday, 5 May 2012 at 17:48:34 UTC, bearophile wrote:
Ideally the most useful result is a mutable one that is 
implicitly castable to immutable if the mapping function is 
pure. But I don't know if this is always possible.


Implicit conversion to immutable would only work if array() is 
strongly pure, but this would require the passed in range type to 
have no non-immutable indirections (besides needing a pure 
implementation of array(), which is currently not the case due to 
appender, but this can be fixed). OTOH, I think it _could_ work 
for ranges operating on originally immutable data, but it seems 
like it doesn't typecheck in today's DMD/Phobos:


———
auto array(Range)(Range r)
if (isIterable!Range && !isNarrowString!Range)
{
  alias Unqual!(ForeachType!Range) E;
  E[] result;
  foreach (e; r) result ~= e;
  return result;
}

void main() {
  immutable x = [1, 2, 3];
  immutable y = array(filter!"a == 3"(x));
}
———

David

Re: Why typedef's shouldn't have been removed :(

[Mehrdad]

Er, the point is, there are functions ALREADY using size_t, and I 
need to figure out which parameters those are.


On Saturday, 5 May 2012 at 18:42:05 UTC, Gor Gyolchanyan wrote:
The effect is the same. You have a new type with a new init, 
that

behaves the same way.

On Sat, May 5, 2012 at 10:38 PM, Mehrdad 
 wrote:

The one with TypeDef?

That's not how it's defined though.

On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote:


See my version.

Re: Why typedef's shouldn't have been removed :(

[Gor Gyolchanyan]

well, there's no solution to it of the alias is in use, no matter what
alternatives are.

On Sat, May 5, 2012 at 10:43 PM, Mehrdad  wrote:
> Er, the point is, there are functions ALREADY using size_t, and I need to
> figure out which parameters those are.
>
>
> On Saturday, 5 May 2012 at 18:42:05 UTC, Gor Gyolchanyan wrote:
>>
>> The effect is the same. You have a new type with a new init, that
>> behaves the same way.
>>
>> On Sat, May 5, 2012 at 10:38 PM, Mehrdad  wrote:
>>>
>>> The one with TypeDef?
>>>
>>> That's not how it's defined though.
>>>
>>> On Saturday, 5 May 2012 at 18:31:44 UTC, Gor Gyolchanyan wrote:


 See my version.
>
>
>



-- 
Bye,
Gor Gyolchanyan.

Re: Why typedef's shouldn't have been removed :(

[Mehrdad]

One solution is to bring back typedef, at least for non-classes 
and non-interfaces.


Another is to change the definition of size_t.

Neither of which anyone except the compiler/library developers 
can fix.



On Saturday, 5 May 2012 at 18:52:57 UTC, Gor Gyolchanyan wrote:
well, there's no solution to it of the alias is in use, no 
matter what

alternatives are.

Re: True disposable objects (add "Finalized!" assertion)

[Simen Kjaeraas]

On Fri, 04 May 2012 21:07:20 +0200, Steven Schveighoffer  
 wrote:


On Fri, 04 May 2012 14:50:06 -0400, Simen Kjaeraas  
 wrote:


I believe the idea was that it'd blow up if you use it unwisely. clear  
might
do that, but if you're unlucky, it'll 'work' just fine, giving you  
problems

later.


clear zeros out the vtable, so it's highly unlikely it "just works".


Final functions still work, as they don't need the vtable.

Re: Return by 'ref' problems...

[Artur Skawina]

On 05/05/12 12:10, Manu wrote:
> On 5 May 2012 09:09, Artur Skawina  > wrote:
> 
> On 05/05/12 01:32, Manu wrote:
> > On 4 May 2012 21:51, Artur Skawina    >> wrote:
> >
> > On 05/04/12 15:57, Manu wrote:
> > > Yeah I really hate this too. I'd like to see const(T) strictly 
> enforced, considering the potential for ambiguity in other situations.
> > >
> > > But I'm still stuck! :(
> > > How can I do what I need to do?
> >
> > If 'auto' is not an option:
> >
> >   alias ref const(S) function() FT;
> >   FT fp;
> >
> > (it's needed for things like 'extern (C)' too)
> >
> >
> > Huzzah! This is indeed the solution! I haven't seen another solution 
> that works. now I just need to make sure I generate a unique name for the 
> alias...
> >
> > I don't think this is needed for extern (C), I declare extern (C) 
> function pointers all the time without any trick..?
> 
>   void f(extern (C) int function(double) a);

The compiler won't directly accept "void f(extern (C) int function(double) a)" 
when declaring
or defining the function, so the extra alias step is necessary, like in your 
'ref' case.

> Hmm, actually, this makes me question my code...
> 
> struct Thing
> {
>   extern (C) void function() funcPtr;
> }
> 
> Have I declared a pointer to an extern(C) function, or have I declared an 
> extern(C) variable funcPtr that is a regular D-call function?
> extern(C) variables only really make sense in the global scope, where they 
> would have C-style name mangling applied...

   alias extern (C) void function() F;
   F f1;
   extern (C) F f2;

'f1' is a D pointer a C function, 'f2' is a C pointer to C function (ie f2's 
name isn't mangled).


   extern (C) void function() f3;

f3 is a C pointer to C function (think 'extern (C) { void function() f3; }').


   alias void function() DF;
   extern (C) DF f4;

f4 is a C pointer to a D function.


I'd stick to the alias method for every case where the difference actually 
matters...

artur

Re: Why typedef's shouldn't have been removed :(

[Chris Cain]

On Saturday, 5 May 2012 at 18:43:41 UTC, Mehrdad wrote:
Er, the point is, there are functions ALREADY using size_t, and 
I need to figure out which parameters those are.


Out of curiosity, why would you need to "know" which parameters
are size_t? True, size_t is either uint or ulong and you can't
really know for sure if you have a uint or ulong and it was
actually a size_t ... but why would you need to know?

Re: Why typedef's shouldn't have been removed :(

[Mehrdad]

That's *such* a lame question...

Even if I _couldn't_ tell you a reason, that'd still be a lame
question, because the *entire point* of reflection is to access
type information information about the program... if for nothing
other than printing it out for the user.

But it's more than that: it's the same darn reason why you need
to distinguish between
void* and HWND -- it's an ERROR!

In other words, this must NOT compile!

auto call(F, T...)(F func, T args) { return func(args); }
void test(uint) { }
void main() { call!(typeof(&test), size_t)(&test, 1); }

If you're still asking "why shouldn't it compile" then you should
look up what "type safety" means.


On Saturday, 5 May 2012 at 21:24:50 UTC, Chris Cain wrote:

On Saturday, 5 May 2012 at 18:43:41 UTC, Mehrdad wrote:
Er, the point is, there are functions ALREADY using size_t, 
and I need to figure out which parameters those are.


Out of curiosity, why would you need to "know" which parameters
are size_t? True, size_t is either uint or ulong and you can't
really know for sure if you have a uint or ulong and it was
actually a size_t ... but why would you need to know?

Re: Why typedef's shouldn't have been removed :(

[Matt Peterson]

On Saturday, 5 May 2012 at 23:41:52 UTC, Mehrdad wrote:

That's *such* a lame question...

Even if I _couldn't_ tell you a reason, that'd still be a lame
question, because the *entire point* of reflection is to access
type information information about the program... if for nothing
other than printing it out for the user.

But it's more than that: it's the same darn reason why you need
to distinguish between
void* and HWND -- it's an ERROR!

In other words, this must NOT compile!

auto call(F, T...)(F func, T args) { return func(args); }
void test(uint) { }
void main() { call!(typeof(&test), size_t)(&test, 1); }

If you're still asking "why shouldn't it compile" then you 
should

look up what "type safety" means.



That doesn't compile on x86_64.

The point of size_t is to be the native word-sized integer for
the platform, and it does exactly that.

Re: nginx reverse proxy for vibe tutorial

[James Miller]

On Friday, 4 May 2012 at 11:54:04 UTC, David wrote:
* using `try_files`, nginx complains that you can't use 
proxy_pass
inside a named location (like `@vibe`), which means you can't 
use
try_files to serve arbitrary static files, hence the massive 
list of

extensions.


why not doing:


root /path/to/static

location / {
try_files $uri @app_proxy
}

location @app_proxy {
...
}


I tried that, nginx complained endlessly about it. I'm not sure 
why and I would prefer to use that version.


Also, I need to make an adjustment to my configuration, the 
$body_bytes_sent doesn't work the way I thought, so you actually 
need to do


server {
   ...
   proxy_set_body $request_body;
   ...
   // Remove proxy_set_header Content-length... line
}

Re: Why typedef's shouldn't have been removed :(

[Jonathan M Davis]

On Saturday, May 05, 2012 20:43:40 Mehrdad wrote:
> Er, the point is, there are functions ALREADY using size_t, and I
> need to figure out which parameters those are.

In what situation would it matter? If you're writing the code yourself, then 
you have access to the function and can see that it's a size_t, so any code 
that you write which interacts with it will then be written to use size_t. If 
you're using compile-time reflection, then you'll get uint or ulong, depending 
on the architecture, but then uint or ulong is what you _need_ for that 
architecture, so using uint or ulong at that point would be correct. As far as 
I can tell, the fact that it was originally a size_t would be irrelevant at 
that point.

- Jonathan M Davis

Re: Why typedef's shouldn't have been removed :(

[Mehrdad]

The point of size_t is to be the native word-sized integer for 
the platform


"Native word-sized integer" is such a blurry term, but of course
you
wouldn't know this without understanding why C has a gazillion
"native" integer types... (hint: if you're trying to justify
these with today's x86 processors, you're already on the wrong
track)

The point of size_t is for it to be able to represent the size of
something. That's all.

The point of sizediff_t is for it to be able to represent the
difference between two size_t's. That's all.

The point of ptrdiff_t is for it to be able to represent the
difference between two pointers. That's all.

Those three need NOT be the same size on the same machine, and
they need NOT be the same as the "fastest" integers on any
platform.
That's the whole point of std.stdint, in case you hadn't heard of
it.




That doesn't compile on x86_64.


I can't tell if you're missing my point or what...
In case that was unclear:
* I'm saying that shouldn't compile on *ANY* platform. 

What you're saying is like saying "dchar[] function()" should be
interchangeable with "uint[] function()" just because they're the 
same data on the same

platform.

Or like saying class Bar { } and class Foo { } should be
interchangeable because there's no actual difference between them.

Or like saying "HWND function()" and "HANDLE function()" and
"void* function()" should be
interchangeable because they're all the same anyway.

Kind of silly IMO.

Re: Why typedef's shouldn't have been removed :(

[Matt Peterson]

I understand you're frustrated, but you don't need to be so
hostile. I agree with most of what you've said on this thread.
And just because I made a short comment doesn't mean I don't know
about std.stdint, sizediff_t, etc. My point was to say that
size_t is supposed to be the size of the architecture's word. I
said nothing about it being the "fastest" type or even whether it
was useful . I would be very interested if you have a better
solution for the integer typing/naming problem.

There definitely needs to be way to define a type that can't
implicitly cast to its base type. The problem is that the
original typedef did do implicit casting away, and that has
potential to cause confusion when porting from C or D1. I don't
see that as much of a problem, but others might.




On Sunday, 6 May 2012 at 02:25:54 UTC, Mehrdad wrote:
The point of size_t is to be the native word-sized integer for 
the platform


"Native word-sized integer" is such a blurry term, but of course
you
wouldn't know this without understanding why C has a gazillion
"native" integer types... (hint: if you're trying to justify
these with today's x86 processors, you're already on the wrong
track)

The point of size_t is for it to be able to represent the size 
of

something. That's all.

The point of sizediff_t is for it to be able to represent the
difference between two size_t's. That's all.

The point of ptrdiff_t is for it to be able to represent the
difference between two pointers. That's all.

Those three need NOT be the same size on the same machine, and
they need NOT be the same as the "fastest" integers on any
platform.
That's the whole point of std.stdint, in case you hadn't heard 
of

it.




That doesn't compile on x86_64.


I can't tell if you're missing my point or what...
In case that was unclear:
* I'm saying that shouldn't compile on *ANY* platform. 

What you're saying is like saying "dchar[] function()" should be
interchangeable with "uint[] function()" just because they're 
the same data on the same

platform.

Or like saying class Bar { } and class Foo { } should be
interchangeable because there's no actual difference between 
them.


Or like saying "HWND function()" and "HANDLE function()" and
"void* function()" should be
interchangeable because they're all the same anyway.

Kind of silly IMO.

Re: Why typedef's shouldn't have been removed :(

[Mehrdad]

On Sunday, 6 May 2012 at 03:15:01 UTC, Matt Peterson wrote:
I understand you're frustrated, but you don't need to be so 
hostile.


You're completely right... I apologize about that, it was 
completely my fault.
I've indeed been pretty frustrated at this typedef nonsense (and 
the like), since it's made something otherwise elegant become 
something very annoying and

time-wasting.

To @Chris Cain as well, my response there was rather hostile too 
-- my apologies about that as well.



I agree with most of what you've said on this thread. And just 
because I made a short comment doesn't mean I don't know about 
std.stdint, sizediff_t, etc. My point was to say that size_t is 
supposed to be the size of the architecture's word. I said 
nothing about it being the "fastest" type or even whether it 
was useful . I would be very interested if you have a better 
solution for the integer typing/naming problem.


Right, but what I was saying was that that *isn't* what it's 
meant to be! It's just a *size* type, not a *word* of any kind... 
(think about systems with interleaving pointers, for example, x86 
with segmentation -- the notion of a "word" isn't so obvious 
anymore, when denoting sizes)



There definitely needs to be way to define a type that can't 
implicitly cast to its base type. The problem is that the 
original typedef did do implicit casting away, and that has 
potential to cause confusion when porting from C or D1. I don't 
see that as much of a problem, but others might.


Yeah, I still don't understand what the "potential to cause 
confusion" was.
Was it *actually* causing a significant problem, or was it just a 
"potential" problem?

Re: Why typedef's shouldn't have been removed :(

[Matt Peterson]

On Sunday, 6 May 2012 at 03:28:32 UTC, Mehrdad wrote:


Right, but what I was saying was that that *isn't* what it's 
meant to be! It's just a *size* type, not a *word* of any 
kind... (think about systems with interleaving pointers, for 
example, x86 with segmentation -- the notion of a "word" isn't 
so obvious anymore, when denoting sizes)




Yeah, figuring out what to name something is always a challenge, 
and the huge variety and complexity of modern, and even 
not-so-modern processors doesn't help at all.




There definitely needs to be way to define a type that can't 
implicitly cast to its base type. The problem is that the 
original typedef did do implicit casting away, and that has 
potential to cause confusion when porting from C or D1. I 
don't see that as much of a problem, but others might.


Yeah, I still don't understand what the "potential to cause 
confusion" was.
Was it *actually* causing a significant problem, or was it just 
a "potential" problem?


The issue is if someone new to D2 is porting code from C or D1, 
they would get all kinds of weird errors caused by using typedef 
instead of D2's alias and trying to do math or expecting implicit 
casting to work. But D2 is a different language, with different 
syntax and semantics. Anyone expecting copied C to "just work" in 
D2 is expecting a miracle, but that's not to say we can't try to 
make it as easy as possible.


IMO, alias is a much better name than typedef, which is quite 
generic because technically any struct, class, or even function 
declaration is defining a new type. But adding a new keyword is 
ugly, assuming you can think of a good one, so typedef is 
probably the best choice. The only other alternative is reusing 
existing keywords, but I can't even think of a good choice. Does 
any of static/const/immutable/etc. alias sound good to anyone?