Hi, I'm testing this code:

  [0:gradha@noir:0] [~/test]$ cat hello.d
  import std.stdio;
  import std.date;

  int main()
  {
      int bad_date = getUTCtime();
      d_time good_date = getUTCtime();
      writefln("This is bad: %s", toDateString(bad_date));
      writefln("This is good: %s", toDateString(good_date));
      return 0;
  }
  [0:gradha@noir:0] [~/test]$ ./hello
  This is bad: Sun Dec 07 1969
  This is good: Sat Dec 31 2005

Obviously d_time types should not be converted to ints. From str.date documentation I didn't see any warnings about this. In fact, I thought a d_time type would be just like C's simple time data type (t_time) and there would be no problems doing this.

The example shows otherwise. Shouldn't the compiler give an error
about the conversion? I didn't find any warning switches on dmd's
command line help to turn on verbosity about such obvious conversion
mistakes. Is this maybe a bug in dmd allowing to convert silently
a d_time value to int? I'm using dmd 0.141.

Grzegorz Adam Hankiewicz wrote:

[...]
> I didn't find any warning switches
> on dmd's command line help to turn on verbosity about such
> obvious conversion mistakes.
[...]

Maybe you were too embarressed to see the "-w" warning switch on the command line help.

Maybe you have not read http://www.digitalmars.com/d/warnings.html.

But if you have a C background as your comparison with t_time suggests you should know the implicit conversion rules obeyed by C and that therefore assigning to a variable may cause loss of data, if the type of the variable is not known exactly to you.

It depends on your habits of handlinmg risks what to do in case of unsureness.

You decided to take a risk, lost and now critisizes D.

You could have stated your prerequisite by inserting code like
  assert( typeof(getUTCtime()).sizeof<= int.sizeof);
and would have been on the warned side forever.

-manfred

El Sat, 31 Dec 2005 19:34:53 +0000, Manfred Nowak escribió:
> Maybe you were too embarressed to see the "-w" warning switch on the command line help.

Embarressed? No, if I was embarrassed by every mistake I do I would never ever get out of my mother's basement (oh, wait).

I apologise for not having read correctly the output of dmd on the command line and causing so much trouble.

In article <pan.2005.12.31.11.29.06.445640@ya.com>, Grzegorz Adam Hankiewicz says...
>
>Hi, I'm testing this code:
>
>  [0:gradha@noir:0] [~/test]$ cat hello.d
>  import std.stdio;
>  import std.date;
> 
>  int main()
>  {
>      int bad_date = getUTCtime();
>      d_time good_date = getUTCtime();
>      writefln("This is bad: %s", toDateString(bad_date));
>      writefln("This is good: %s", toDateString(good_date));
>      return 0;
>  }
>  [0:gradha@noir:0] [~/test]$ ./hello
>  This is bad: Sun Dec 07 1969
>  This is good: Sat Dec 31 2005
>
>Obviously d_time types should not be converted to ints. From str.date documentation I didn't see any warnings about this. In fact, I thought a d_time type would be just like C's simple time data type (t_time) and there would be no problems doing this.
>
>The example shows otherwise. Shouldn't the compiler give an error
>about the conversion? I didn't find any warning switches on dmd's
>command line help to turn on verbosity about such obvious conversion
>mistakes. Is this maybe a bug in dmd allowing to convert silently
>a d_time value to int? I'm using dmd 0.141.
>

d_time is an alias rather than a typedef meaning that it is not actually a new type

Currently in data.d, d_time is declared as "alias long d_time;" Perhaps this should be changed "typedef long d_time;"? I think it should

In article <dpbd1t$31bq$1@digitaldaemon.com>, Ben Phillips says...
>
>In article <pan.2005.12.31.11.29.06.445640@ya.com>, Grzegorz Adam Hankiewicz says...
>>
>>Hi, I'm testing this code:
>>
>>  [0:gradha@noir:0] [~/test]$ cat hello.d
>>  import std.stdio;
>>  import std.date;
>> 
>>  int main()
>>  {
>>      int bad_date = getUTCtime();
>>      d_time good_date = getUTCtime();
>>      writefln("This is bad: %s", toDateString(bad_date));
>>      writefln("This is good: %s", toDateString(good_date));
>>      return 0;
>>  }
>>  [0:gradha@noir:0] [~/test]$ ./hello
>>  This is bad: Sun Dec 07 1969
>>  This is good: Sat Dec 31 2005
>>
>>Obviously d_time types should not be converted to ints. From str.date documentation I didn't see any warnings about this. In fact, I thought a d_time type would be just like C's simple time data type (t_time) and there would be no problems doing this.
>>
>>The example shows otherwise. Shouldn't the compiler give an error
>>about the conversion? I didn't find any warning switches on dmd's
>>command line help to turn on verbosity about such obvious conversion
>>mistakes. Is this maybe a bug in dmd allowing to convert silently
>>a d_time value to int? I'm using dmd 0.141.
>>
>
>d_time is an alias rather than a typedef meaning that it is not actually a new type
>
>Currently in data.d, d_time is declared as "alias long d_time;" Perhaps this should be changed "typedef long d_time;"? I think it should
>

It does not matter whether d_time is a typedef or an alias. The fact remains that if you assign a long (i.e., d_time) to an int, implicit conversion will occur.

#  typedef long d_time;
#  d_time dtime;
#  int time;
#
#  dtime = cast(d_time)1000000000000000000;
#  time  = dtime;
#  writefln(time);

output:

C:\d>dtime
-1486618624

The documentation clearly states that a typedef will be implicitly converted to it's base type during assignment.

See:
http://www.digitalmars.com/d/type.html
Rule number 1 under "Usual Arithmetic Conversions"

Regards,
Andrew

a.c.edwards wrote:

[...]
> The documentation clearly states that a typedef will be implicitly converted to it's base type during assignment.
[...]

Sorry, there is no such clear statement in the docs.

Assignment is not an _arithmetic_ operator.

According to the specs the result of an assignment of a typedef'd type to any other type than its base type is not defined.

-manfred

Manfred Nowak wrote:
> a.c.edwards wrote:
> 
> [...]
> 
>>The documentation clearly states that a typedef will be
>>implicitly converted to it's base type during assignment.
> 
> [...]
> 
> Sorry, there is no such clear statement in the docs.
> 
> Assignment is not an _arithmetic_ operator.
> 
> According to the specs the result of an assignment of a typedef'd type to any other type than its base type is not defined.
> 
> -manfred

Quoted directly from http://digitalmars.com/d/type.html
#########################
 D has a lot of types, both built in and derived. It would be tedious to require casts for every type conversion, so implicit conversions step in to handle the obvious ones automatically.

A typedef can be implicitly converted to its underlying type, but going the other way requires an explicit conversion. For example:

# typedef int myint;
# int i;
# myint m;
# i = m;             // OK
# m = i;             // error
# m = cast(myint)i;  // OK
#########################

-- Chris Sauls

In article <Xns973FEC134871Asvv1999hotmailcom@63.105.9.61>, Manfred Nowak says...
>
>a.c.edwards wrote:
>
>[...]
>> The documentation clearly states that a typedef will be implicitly converted to it's base type during assignment.
>[...]
>
>Sorry, there is no such clear statement in the docs.
>
>Assignment is not an _arithmetic_ operator.
>
>According to the specs the result of an assignment of a typedef'd type to any other type than its base type is not defined.
>
>-manfred
>
>

Maybe you and I are reading two completely different specs. The one I read (i.e. the link I provided) was extremely clear to me. Or maybe it's just that my inexperience as a programmer does not grant me the necessary required knowlege to discern what is clear from what is not. But I would go as far as to suggest that if is clear to neophyte, then it is pretty damn clear to just about anyone else except those who chose not to read it.

Andrew

On Tue, 03 Jan 2006 09:12:27 +1100, Manfred Nowak <svv1999@hotmail.com> wrote:

> a.c.edwards wrote:
>
> [...]
>> The documentation clearly states that a typedef will be
>> implicitly converted to it's base type during assignment.
> [...]
>
> Sorry, there is no such clear statement in the docs.
>
> Assignment is not an _arithmetic_ operator.
>
> According to the specs the result of an assignment of a typedef'd
> type to any other type than its base type is not defined.

I suggest that the 'mistake' in that part of the documentation (Usual Arithmetic Conversions) is that it uses the word "arithmetic" when it really just means "numeric".

-- 
Derek Parnell
Melbourne, Australia

Derek Parnell wrote:

[...]
> uses the word "arithmetic" when it  really just means "numeric".

Changing the wording would not help much. Please see my answer to "Chris Sauls" posting.

-manfred