On Wed, Dec 12, 2012 at 9:07 AM, Denis Koroskin <2korden@gmail.com> wrote:

> What's now is safer than what you propose. You can always create your own data type that would automatically truncate result if you wish so.


:-)

I should not have used the word "safe" there. All I meant was "safer" than C++ which allows implicit conversion form int to short and long to int.

Yes, I am now using my own User Type.

Regards
- Puneet

On 2012-09-12 00:12, js.mdnq <js_adddot+mdng@gmail.com> wrote:

> struct bbyte {
> byte value;
> ...
> }
>
> bbyte a; bbyte b;
>
> b = a + b; // uses bbyte's operators and casts to do the computation and assignment but then returns a bbyte instead of an int.
>
> You should have no problems implicitly converting bbyte to built in types or built in types to bbyte.

Not entirely true. Converting from bbyte to built-in works, but these
are to my knowledge currently impossible:

void foo(bbyte b);
byte b;

foo(b); // No conversion.


bbyte bar( ) {
    byte b;
    return b;
}


-- 
Simen

On Wednesday, December 12, 2012 09:23:35 Simen Kjaeraas wrote:
> On 2012-09-12 00:12, js.mdnq <js_adddot+mdng@gmail.com> wrote:
> > struct bbyte {
> > byte value;
> > ...
> > }
> > 
> > bbyte a; bbyte b;
> > 
> > b = a + b; // uses bbyte's operators and casts to do the computation and assignment but then returns a bbyte instead of an int.
> > 
> > You should have no problems implicitly converting bbyte to built in types or built in types to bbyte.
> 
> Not entirely true. Converting from bbyte to built-in works, but these are to my knowledge currently impossible:
> 
> void foo(bbyte b);
> byte b;
> 
> foo(b); // No conversion.
> 
> 
> bbyte bar( ) {
>      byte b;
>      return b;
> }

You can do it with alias this, but the current lack of ability to have multiple alias thises probably makes it so that you can't use it for converting in both directions unless you want to directly alias it to the member variable holding the value (which eans no checks or whatever else you might want to do in bbyte). Once we can have multiple alias thises though, that shouldn't be problem anymore.

- Jonathan M Davis

On 2012-17-12 10:12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, December 12, 2012 09:23:35 Simen Kjaeraas wrote:
>> On 2012-09-12 00:12, js.mdnq <js_adddot+mdng@gmail.com> wrote:
>> > struct bbyte {
>> > byte value;
>> > ...
>> > }
>> >
>> > bbyte a; bbyte b;
>> >
>> > b = a + b; // uses bbyte's operators and casts to do the computation  
>> and
>> > assignment but then returns a bbyte instead of an int.
>> >
>> > You should have no problems implicitly converting bbyte to built in
>> > types or built in types to bbyte.
>>
>> Not entirely true. Converting from bbyte to built-in works, but these
>> are to my knowledge currently impossible:
>>
>> void foo(bbyte b);
>> byte b;
>>
>> foo(b); // No conversion.
>>
>>
>> bbyte bar( ) {
>>      byte b;
>>      return b;
>> }
>
> You can do it with alias this, but the current lack of ability to have
> multiple alias thises probably makes it so that you can't use it for
> converting in both directions unless you want to directly alias it to the
> member variable holding the value (which eans no checks or whatever else you
> might want to do in bbyte). Once we can have multiple alias thises though,
> that shouldn't be problem anymore.

Really? This certainly does not compile for me:


struct bbyte {
    byte b;
    alias b this;
}

void bar(bbyte b) {}

bbyte baz() {
    byte b;
    return b; // cannot implicitly convert expression (b) of type byte to bbyte
}

void main() {
    byte b;
    bar(b); // function bar (bbyte b) is not callable using argument types (byte)
}


This is also the reason for bug #8570

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

-- 
Simen

On Wednesday, 12 December 2012 at 08:23:48 UTC, Simen Kjaeraas wrote:
> On 2012-09-12 00:12, js.mdnq <js_adddot+mdng@gmail.com> wrote:
>
>> struct bbyte {
>> byte value;
>> ...
>> }
>>
>> bbyte a; bbyte b;
>>
>> b = a + b; // uses bbyte's operators and casts to do the computation and assignment but then returns a bbyte instead of an int.
>>
>> You should have no problems implicitly converting bbyte to built in types or built in types to bbyte.
>
> Not entirely true. Converting from bbyte to built-in works, but these
> are to my knowledge currently impossible:
>
> void foo(bbyte b);
> byte b;
>
> foo(b); // No conversion.
>
>
> bbyte bar( ) {
>     byte b;
>     return b;
> }


What I mean is that you use bbyte for all your arithmetic operations and computations.  When you need to convert it to a byte(hopefully at the end of the process), you can use an implicit cast.


struct bbyte {
	byte b;
	byte opCast(bbyte a) { return a.b; }
	alias b this;


	bbyte bar(byte b) { bbyte q; q.b = b; return q; }

	byte foo(bbyte b) {  return b.b; }
}

byte bar2(byte b) { return b; }



int main(string[] argv)
{

	bbyte bb;
	byte b;

	bb.foo(bb); 		
	bb.bar(b);
	b = bb;
	bb = b;
}

the point is no explicit op casts are required. Essentially a bbyte is a byte. One can overload all the operators that are needed for bit manipulation, even using asm if necessary and one should be able to hide most of the details. `alias this` might not stop some of the value propagation in some cases. If one only converts to the built-in types when actually needed(when passing to and from routines that use them) but uses bbyte for all bit manipulations it shouldn't be much of a problem(if at all).


The idea is that conversion from bbyte to byte does not induce an expansion to int, only the arithmetic operations. Hence, overriding them can stop that.

but something like

byte b1;
byte b2;
bbyte b3 = b1 + b2;

is computing the arithmetic operation from byte(which converts to an int). This is why I say one must use bbytes for all arithmetic operations to solve that problem. (or write a cast for int, if you just don't want to deal with it but don't mind the expansion)

But this works:

byte b1;
byte b2;
bbyte b3;
b3 = b1 + b2;

if one has bbyte opAssign(int i) { this.b = cast(byte)i; return this; } in bbyte.

which avoids having to do b3 = cast(byte)(b1 + b2) which I think was what the original post was about.

On Wednesday, December 12, 2012 10:42:31 Simen Kjaeraas wrote:
> Really? This certainly does not compile for me:
> 
> 
> struct bbyte {
> byte b;
> alias b this;
> }
> 
> void bar(bbyte b) {}
> 
> bbyte baz() {
> byte b;
> return b; // cannot implicitly convert expression (b) of type byte to
> bbyte
> }
> 
> void main() {
> byte b;
> bar(b); // function bar (bbyte b) is not callable using argument types
> (byte)
> }
> 
> 
> This is also the reason for bug #8570
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=8570

If alias this isn't do an implict conversion, then there's a bug in alias this. That's how implict conversion is done in D, and it's the whole point of alias this.

- Jonathan M Davis

On 12/12/2012 10:25 AM, Jonathan M Davis wrote:
> If alias this isn't do an implict conversion, then there's a bug in alias
> this. That's how implict conversion is done in D, and it's the whole point
> of alias this.

And it does, as I relied on this to do the halffloat implementation.

On Wednesday, December 12, 2012 13:35:59 Walter Bright wrote:
> On 12/12/2012 10:25 AM, Jonathan M Davis wrote:
> > If alias this isn't do an implict conversion, then there's a bug in alias this. That's how implict conversion is done in D, and it's the whole point of alias this.
> 
> And it does, as I relied on this to do the halffloat implementation.

Simen's example doesn't seem to work though, so he appears to have found a bug. Certainly, I don't see anything wrong with it, but alias this doesn't seem to work for it. Regardless, my point was that if there's a case where alias this isn't doing an implicit conversion, then it's a bug, because that's the whole reason that it exists.

- Jonathan M Davis

On 2012-22-13 04:12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Wednesday, December 12, 2012 13:35:59 Walter Bright wrote:
>> On 12/12/2012 10:25 AM, Jonathan M Davis wrote:
>> > If alias this isn't do an implict conversion, then there's a bug in  
>> alias
>> > this. That's how implict conversion is done in D, and it's the whole  
>> point
>> > of alias this.
>>
>> And it does, as I relied on this to do the halffloat implementation.
>
> Simen's example doesn't seem to work though, so he appears to have found a
> bug. Certainly, I don't see anything wrong with it, but alias this doesn't
> seem to work for it. Regardless, my point was that if there's a case where
> alias this isn't doing an implicit conversion, then it's a bug, because that's
> the whole reason that it exists.

So it is supposed to work? I've always thought this was a deliberate design
choice. I guess I'll file a bug, then. Here:

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

Kenji, you here? :p

-- 
Simen

D does not support such implicit *construction* in return statement and
function argument.
It is a current language design, and not a bug.

Kenji Hara


2012/12/13 Simen Kjaeraas <simen.kjaras@gmail.com>

> On 2012-22-13 04:12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
>
>  On Wednesday, December 12, 2012 13:35:59 Walter Bright wrote:
>>
>>> On 12/12/2012 10:25 AM, Jonathan M Davis wrote:
>>> > If alias this isn't do an implict conversion, then there's a bug in
>>> alias
>>> > this. That's how implict conversion is done in D, and it's the whole
>>> point
>>> > of alias this.
>>>
>>> And it does, as I relied on this to do the halffloat implementation.
>>>
>>
>> Simen's example doesn't seem to work though, so he appears to have found a
>> bug. Certainly, I don't see anything wrong with it, but alias this doesn't
>> seem to work for it. Regardless, my point was that if there's a case where
>> alias this isn't doing an implicit conversion, then it's a bug, because
>> that's
>> the whole reason that it exists.
>>
>
> So it is supposed to work? I've always thought this was a deliberate design choice. I guess I'll file a bug, then. Here:
>
> http://d.puremagic.com/issues/**show_bug.cgi?id=9147<http://d.puremagic.com/issues/show_bug.cgi?id=9147>
>
> Kenji, you here? :p
>
> --
> Simen
>