May 08, 2012
Am 08.05.2012 16:03, schrieb bearophile:
> Steven Schveighoffer:
> 
>> But making std.typecons.TypeDef work *is* a valid path to get what you want (typedefs that work like they used to).  If that isn't possible, let's fix the language constructs that are blocking it!
> 
> Right.
> 
> Bye,
> bearophile

Maybe it's not directly related to this topic, but shouldn't that be rather part of druntime?
May 08, 2012
On Tuesday, May 08, 2012 20:58:50 mta`chrono wrote:
> Am 08.05.2012 16:03, schrieb bearophile:
> > Steven Schveighoffer:
> >> But making std.typecons.TypeDef work *is* a valid path to get what you want (typedefs that work like they used to). If that isn't possible, let's fix the language constructs that are blocking it!
> > 
> > Right.
> > 
> > Bye,
> > bearophile
> 
> Maybe it's not directly related to this topic, but shouldn't that be rather part of druntime?

Only if something else in druntime needs it, which it doesn't.

- Jonathan M Davis
May 09, 2012
>> Maybe it's not directly related to this topic, but shouldn't that be rather part of druntime?
> 
> Only if something else in druntime needs it, which it doesn't.
> 
> - Jonathan M Davis

There is a real trend to purify the language. I also think it's the right decision to replace compiler intrinsics / language feature with their library counterparts. Moving stuff to phobos is fine as long as you use phobos. But I'm using tango and druntime. I haven't even installed phobos on my system. The same impacts deimos. People tend to create unneccessary phobos dependencys.
May 09, 2012
On Wednesday, May 09, 2012 10:00:37 mta`chrono wrote:
> >> Maybe it's not directly related to this topic, but shouldn't that be rather part of druntime?
> > 
> > Only if something else in druntime needs it, which it doesn't.
> > 
> > - Jonathan M Davis
> 
> There is a real trend to purify the language. I also think it's the right decision to replace compiler intrinsics / language feature with their library counterparts. Moving stuff to phobos is fine as long as you use phobos. But I'm using tango and druntime. I haven't even installed phobos on my system. The same impacts deimos. People tend to create unneccessary phobos dependencys.

In general, we're not sticking anything in druntime unless it needs to be there. It's also pretty much expected that projects will use Phobos. druntime isn't even provided at a separate library when distributed with dmd. If you're specifically trying to avoid using Phobos, you can do that, but don't expect stuff that doesn't need to be in druntime to be put into druntime just because you don't want to use D's standard library.

Since Phobos is statically linked at this point, the parts that you don't use wouldn't be pulled in anyway. But you can also copy it from Phobos and put it in your project if you want to (as long as it doesn't have a lot of other dependencies in Phobos).

Personally, I don't know how you could get by without using Phobos for at least std.traits unless you avoid templates (which would _really_ be reducing D's power - I'd hate to use D without templates), since it's a _lot_ harder to have good template constraints without std.traits.

- Jonathan M Davis
May 09, 2012
"Mehrdad" , dans le message (digitalmars.D:166381), a écrit :
> On Monday, 7 May 2012 at 20:25:35 UTC, Steven Schveighoffer wrote:
>> On Mon, 07 May 2012 15:48:22 -0400, Mehrdad <wfunction@hotmail.com> wrote:
>>
>> I'm looking at this:
>>
>> m += 5; // ok
>> m = m + 5; // error
>>
>> And thinking, hm.. this is no good :)
> 
> Yeah, that means they were implemented poorly. :P
> It should've been an error for both, because neither of them make
> sense.
> I don't see why the first one couldn't have been an error though,
> so I guess I'll have to dig up old threads on why the first one
> wasn't disallowed, since I can't see why we couldn't just
> disallow it right there...

One reason could be this :
mint, just like int has an opOpAssign!"+" with takes an int, so "m +=
5" is valid...

Using any other rule raises a lot of questions:
 - Should all operators of typedef-type with its base-type parameter be
rewritten to take a typedef-type ?
 - What about returned type?
 - What about methods that are not operators?
 - What about free functions?
 - If something is implicitely castable/promoted to the base type,
should it be implicitely castable to the typedef ?

What choice of typedef would you make?

size_t is a good example of why typedef is poor.
Should this compile, and if it does, what is the type of the result of
the operations ?

typedef uint size_t;
size_t a, b;
a - b;
-b;
a * b;
a * 2;
a * -2;
a * 2u;

I don't think typedef if a good solution to implement a type safe size_t.

Solutions may be found in typesafe langages, but things are not as obvious as you would like them to be.

-- 
Christophe
May 09, 2012
Am 09.05.2012 11:53, schrieb Jonathan M Davis:
> On Wednesday, May 09, 2012 10:00:37 mta`chrono wrote:
>>>> Maybe it's not directly related to this topic, but shouldn't that be rather part of druntime?
>>>
>>> Only if something else in druntime needs it, which it doesn't.
>>>
>>> - Jonathan M Davis
>>
>> There is a real trend to purify the language. I also think it's the right decision to replace compiler intrinsics / language feature with their library counterparts. Moving stuff to phobos is fine as long as you use phobos. But I'm using tango and druntime. I haven't even installed phobos on my system. The same impacts deimos. People tend to create unneccessary phobos dependencys.
> 
> In general, we're not sticking anything in druntime unless it needs to be there. It's also pretty much expected that projects will use Phobos. druntime isn't even provided at a separate library when distributed with dmd. If you're specifically trying to avoid using Phobos, you can do that, but don't expect stuff that doesn't need to be in druntime to be put into druntime just because you don't want to use D's standard library.
> 
> Since Phobos is statically linked at this point, the parts that you don't use wouldn't be pulled in anyway. But you can also copy it from Phobos and put it in your project if you want to (as long as it doesn't have a lot of other dependencies in Phobos).

It's nothing more than a general design decision what belongs into druntime and what doesn't. I don't expect you to do anything just because I say so (Don't believe me!), but since this newsgroup is open for everybody to post his/her crap, I'll do similar. ;-)

The question I had to came is across is "What is druntime?". It provides D's _meat and potatoes_ used for _fundamental_ features of the language like garbage collecting, threads, synchronisation and it's even used for array manipulation. Coding D without druntime is not possible.

Sooner or later dmd will be able to support ARM android or iOS. And then we'll be lucky to only port druntime to the new plattform. Phobos is a really powerfull library but it's too fat with all it's dependencies. (libcurl is one of it).

The reason why C is so powerfull and runs even on a tiny 1,59 €uro AVR processor is quite simple. It's _NOT_ too much coupled to any standard library. There are hundreads glibc, uClibc, bionic, diet libc. just to mention a few.

> Personally, I don't know how you could get by without using Phobos for at least std.traits unless you avoid templates (which would _really_ be reducing D's power - I'd hate to use D without templates), since it's a _lot_ harder to have good template constraints without std.traits.

That's how I do for now: Copying std.traits to tango.core.Traits. It works quite fine unless you start using tango and phobos side by side in a "hybrid" project. That's why I prefer a common core.traits.

> 
> - Jonathan M Davis

Okay, now you got my 50 Cents. Thanks for reading.
May 11, 2012
Okay, I just tried changing "alias void*" to "alias Typedef(void*)", and also "alias HANDLE" to "alias Typedef(HANDLE)", etc.

First error I got?

	HMODULE hAdvapi32 = null;
	...\src\phobos\std\internal\windows\advapi32.d(32):
	Error:
	cannot implicitly convert expression (null) of type typeof(null) to Typedef!(Typedef!(void*,null),Typedef(null))


Which makes sense, except that I'm not sure how to solve it correctly in general...
I think it's a bigger problem than it looks, since 'null' would need to be convertible to everything that's nullable...

ideas?
May 11, 2012
On Fri, 11 May 2012 14:56:45 -0400, Mehrdad <wfunction@hotmail.com> wrote:

> Okay, I just tried changing "alias void*" to "alias Typedef(void*)", and also "alias HANDLE" to "alias Typedef(HANDLE)", etc.
>
> First error I got?
>
> 	HMODULE hAdvapi32 = null;
> 	...\src\phobos\std\internal\windows\advapi32.d(32):
> 	Error:
> 	cannot implicitly convert expression (null) of type typeof(null) to Typedef!(Typedef!(void*,null),Typedef(null))
>
>
> Which makes sense, except that I'm not sure how to solve it correctly in general...
> I think it's a bigger problem than it looks, since 'null' would need to be convertible to everything that's nullable...

This is a frequent problem with null.  Since null is its own type now, it doesn't play nice with custom types, only builtins enjoy special treatment for null.

> ideas?

probably something like opBool:

struct S
{
  int x;
  static S opNull() { return S(0);}
}

S s = null; // equivalent to S(0);

-Steve
May 11, 2012
On Friday, 11 May 2012 at 19:04:52 UTC, Steven Schveighoffer wrote:
> This is a frequent problem with null.  Since null is its own type now, it doesn't play nice with custom types, only builtins enjoy special treatment for null.

It is????? O_________O
(welcome to Python, lol...)

> probably something like opBool:
>
> struct S
> {
>   int x;
>   static S opNull() { return S(0);}
> }
>
> S s = null; // equivalent to S(0);

Ohhmmmmmmmmmmmm interesting, lemme look at that... thanks
May 11, 2012
On 5/11/12, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> Since null is its own type now..

What were the use-cases for making it a type? Seems odd to declare it:
typeof(null) x;

I mean what could you do with such a type?