Coming from C#, I definitely agree that non-const ref/out
arguments should have to include a 'ref' or '&' in front, much
like pointers do. Silent modification of parameters feels odd to
me for sure. However at this point it's frankly too late to
change it, as the change is not worth the tremend
I think "enum preconditions" are exactly that :-) But I don't
Great! :) This can also be used to specialize construction of
linear algebra types such as vectors, matrices etc to use
stack-allocated value (simd) types when dimensions are fixed and
small.
On 20/05/14 07:21, Iain Buclaw via Digitalmars-d wrote:
On 19 May 2014 23:07, Lionello Lunesu via Digitalmars-d
mailto:digitalmars-d@puremagic.com>> wrote:
On 19/05/14 15:37, Lionello Lunesu wrote:
Have inquired further how to recognize the shuttles at SFO.
FYI: http://www.fl
On Monday, 19 May 2014 at 17:26:25 UTC, w0rp wrote:
Explicit or implicit pass by reference at the call site is a
political argument and it is highly subjective. I'm used to the
current state of affairs (due to coming from C++) and I don't
see anything wrong with it. If you can't tell from a fun
On 20 May 2014 06:21, Iain Buclaw wrote:
>
> On 19 May 2014 23:07, Lionello Lunesu via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On 19/05/14 15:37, Lionello Lunesu wrote:
>>
>>> Have inquired further how to recognize the shuttles at SFO.
>>>
>>
>> FYI: http://www.flysfo.com/to-fr
On 19 May 2014 23:07, Lionello Lunesu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 19/05/14 15:37, Lionello Lunesu wrote:
>
>> Have inquired further how to recognize the shuttles at SFO.
>>
>
> FYI: http://www.flysfo.com/to-from/ebs/shared-ride-vans
>
>
Yeah, shuttles is how Manu g
On Monday, 19 May 2014 at 18:05:29 UTC, Dicebot wrote:
On Sunday, 18 May 2014 at 08:02:59 UTC, bearophile wrote:
deadalnix:
If the machine code is the same, the function can be merged
by the optimizer.
But in general isn't it more efficient to not generate bloat
instead of generating it, de
On Mon, 19 May 2014 15:20:46 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> On Mon, 19 May 2014 15:03:55 -0400, Dicebot wrote:
>
> > On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
> >> On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
> >> wrote:
> >>
> >>> On
On Mon, 19 May 2014 14:33:55 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> The whole POINT of pure functions is that it will return the same
> thing. The fact that it lives in a different piece of memory or not
> is not important. We have to accept that. Any code that DEPENDS on
> that be
On Mon, 19 May 2014 13:11:43 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> On Mon, 19 May 2014 12:35:26 -0400, Jonathan M Davis via
> Digitalmars-d wrote:
>
> > On Mon, 19 May 2014 09:42:31 -0400
> > Steven Schveighoffer via Digitalmars-d
> > wrote:
> >
> >> On Sun, 18 May 2014 09:58:25
Nordlöw:
I personally think we need a completely new language feature in
D with which to compile-time-introspect function call arguments
to check whether they adhere to certain requirements or matches
for example the range of other given types.
I think "enum preconditions" are exactly that :
this at the forums, previously. Does this answer your questions?
To clarify: I personally think we need a completely new language
feature in D with which to compile-time-introspect function call
arguments to check whether they adhere to certain requirements or
matches for example the range of
On Monday, 19 May 2014 at 20:51:22 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 16:23:34 -0400, Dicebot
wrote:
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot
wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schv
the error at run-time, and this is not acceptable. I am missing
something?
My current solution only supports ranges (min max as template
arguments) known at compile-time. It would be nice if we could
add a feature to D that specializes return value of bound
instantiator based upon if its norm
On 19/05/14 15:37, Lionello Lunesu wrote:
Have inquired further how to recognize the shuttles at SFO.
FYI: http://www.flysfo.com/to-from/ebs/shared-ride-vans
On Monday, 19 May 2014 at 21:16:19 UTC, Steven Schveighoffer
wrote:
BTW, you probably shouldn't expect any response from me, I'm
about to go into travel-prep mode, and I likely will not be
checking forums. If you are at dconf, perhaps we can continue
the discussion in person :)
I am not going
On Mon, 19 May 2014 17:14:44 -0400, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 16:56:58 -0400, Ola Fosheim Grøstad
wrote:
I've given several examples
Links?
BTW, you probably shouldn't expect any response from me, I'm about to go
into travel-prep mode, and I likely will not b
On Mon, 19 May 2014 16:56:58 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 19 May 2014 at 18:55:57 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 14:49:41 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 19 May 2014 at 18:33:55 UTC, Steven Schveighoffer wrote:
Then you should have n
On Monday, 19 May 2014 at 18:55:57 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 14:49:41 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 19 May 2014 at 18:33:55 UTC, Steven Schveighoffer
wrote:
Then you should have no problem producing an example, right?
I did. Besides, I think lang
On Mon, 19 May 2014 16:23:34 -0400, Dicebot wrote:
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøst
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot
wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 19 May 2014 at 17:11:43 UTC,
Nordlöw:
because saturated is an instantiator function. Shouldn't it?
I still don't understand how you can design a good enough ranged
integer without something like "enum preconditions". Functions
run at run-time, so currently in D you can't enforce the
correctness of literals for not-enum
Is this giving a compile-time error?
saturated!byte b = 127;
Sorry, I meant something different. I am not sure you can give
compile-time errors in most of the significant cases with the
current D language. Please correct me if I am wrong.
Bye,
bearophile
On Monday, 19 May 2014 at 19:54:07 UTC, bearophile wrote:
Nordlöw:
Bound!byte b = 200;
This is already handled
For example
const b127 = saturated!byte(127);
compiles but
const b128 = saturated!byte(128);
errors as
bound.d(421,32): Error: saturated (inout(byte) x) is not
callable
Nordlöw:
Bound!byte b = 200;
This is already handled
For example
const b127 = saturated!byte(127);
compiles but
const b128 = saturated!byte(128);
errors as
bound.d(421,32): Error: saturated (inout(byte) x) is not
callable using argument types (int)
Is this giving a compile-tim
Another way to improve it is to add to D something like the
"enum preconditions" I've discussed in past. So this bug can be
detected at compile-time:
Bound!byte b = 200;
This is already handled
For example
const b127 = saturated!byte(127);
compiles but
const b128 = saturated!byte(
On Mon, 19 May 2014 15:03:55 -0400, Dicebot wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 19 May 2014 at 17:11:43 UTC, Steven Schveighoffer wrote:
It shouldn't matter. Something that ret
On 05/19/2014 09:03 PM, Dicebot wrote:
immutable(Object*) alloc() pure
{
return new Object();
}
bool oops() pure
{
auto a = alloc();
auto b = alloc();
return a is b;
}
This is a snippet that will always return `true` if memoization is at
work and `false` if strongly pure fu
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 19 May 2014 at 17:11:43 UTC, Steven Schveighoffer
wrote:
It shouldn't matter. Something that returns immutable
references, can return that same thing
On Mon, 19 May 2014 14:49:41 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 19 May 2014 at 18:33:55 UTC, Steven Schveighoffer wrote:
Then you should have no problem producing an example, right?
I did. Besides, I think language constructs should be proven sound a
priori, not post mortem..
On Monday, 19 May 2014 at 18:33:55 UTC, Steven Schveighoffer
wrote:
Anything that uses the order of unrelated addresses is
incorrect outside of the heap code itself.
Nah, not on modern archiectures without GC compaction.
Then you should have no problem producing an example, right?
I did. Be
On Mon, 19 May 2014 13:44:59 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
Returning the same immutable object, when called with the same
immutable parameters, should never cause a break in code, pure or not.
This isn't at all obviou
On Sunday, 18 May 2014 at 08:02:59 UTC, bearophile wrote:
deadalnix:
If the machine code is the same, the function can be merged by
the optimizer.
But in general isn't it more efficient to not generate bloat
instead of generating it, detecting it, and removing it?
Bye,
bearophile
It is m
On Wednesday, 14 May 2014 at 20:10:29 UTC, Nick Sabalausky wrote:
On 5/14/2014 2:28 PM, steven kladitis wrote:
On Tuesday, 13 May 2014 at 13:53:36 UTC, Manu via
Digitalmars-d wrote:
On 13 May 2014 23:24, steven kladitis via Digitalmars-d
wrote:
if the -m64 lets the compiled code use 64 bit r
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer
wrote:
Returning the same immutable object, when called with the same
immutable parameters, should never cause a break in code, pure
or not.
This isn't at all obvious to me. Also I think the "coin flip
trick" represent a class of al
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
wrote:
On Monday, 19 May 2014 at 17:11:43 UTC, Steven Schveighoffer wrote:
It shouldn't matter. Something that returns immutable references, can
return that same thing again if asked the same way. Nobody should be
looking at the addr
On Monday, 19 May 2014 at 17:11:43 UTC, Steven Schveighoffer
wrote:
It shouldn't matter. Something that returns immutable
references, can return that same thing again if asked the same
way. Nobody should be looking at the address in any meaningful
way.
I think this is at odds with generic pro
Explicit or implicit pass by reference at the call site is a
political argument and it is highly subjective. I'm used to the
current state of affairs (due to coming from C++) and I don't see
anything wrong with it. If you can't tell from a function's name
what its going to do with its arguments
On Mon, 19 May 2014 12:35:26 -0400, Jonathan M Davis via Digitalmars-d
wrote:
On Mon, 19 May 2014 09:42:31 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d
wrote:
> On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Da
On Monday, 19 May 2014 at 08:51:11 UTC, Jonathan M Davis via
Digitalmars-d wrote:
Perhaps you're hung up on the fact
that the term "pure" is being used, and you're thinking about
functional
purity?
No, I just don't think it makes much sense the way "pure" is
defined in D. Since it doesn't ac
On Mon, 19 May 2014 09:42:31 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d
> wrote:
>
> > On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via
> > Digitalmars-d wrote:
> >> On Thu, 15 May 2014 08:43:11 -0700
> >>
On 5/18/14, 7:10 AM, David Nadlinger wrote:
... Java classes could just be
translated to "@synchronizable class" or whatever.
Whether we preserve backwards compatibility or not, @synchronizable has
my vote for the bikeshed's color.
On Monday, 19 May 2014 at 01:27:00 UTC, Adam Wilson wrote:
An interesting note: If I use a struct or enum from further up
the file in an interface it compiles fine, but if I use an
interface further down the file in a struct, it throws an error.
It sounds like of on those bugs related to order
On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d
wrote:
On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via
Digitalmars-d wrote:
On Thu, 15 May 2014 08:43:11 -0700
Andrei Alexandrescu via Digitalmars-d
wrote:
> On 5/15/14, 6:28 AM, Dicebot wrote:
> > This is not
On 07/05/14 06:11, Mike wrote:
On Tuesday, 6 May 2014 at 02:20:46 UTC, Lionello Lunesu wrote:
Hi all,
After last year's incident with my tires getting slashed, I'm really
hoping I can do without a car during this year's DConf. How feasible
is this?
I'll be staying at Aloft. Would be great if t
On Sun, 18 May 2014 06:33:55 -0400, Andrei Alexandrescu
wrote:
On 5/17/14, 10:01 PM, Walter Bright wrote:
On 5/14/2014 2:17 PM, Andrei Alexandrescu wrote:
On 5/14/14, 6:33 AM, Yuriy wrote:
4. I consider D a killemall language, that may be potentially used on
tiny AVRs and PICs, where polym
On Sat, 17 May 2014 16:18:07 -0400, FG wrote:
On 2014-05-17 21:35, bearophile wrote:
FG:
and don't forget the extra memory needed to store the tree for fast
key look-up in the hash array.
I think D now uses a linked list for the collision chains (so opCmp is
useless, despite it's still
On Monday, 19 May 2014 at 10:17:17 UTC, evilrat wrote:
On Monday, 19 May 2014 at 09:56:38 UTC, bearophile wrote:
evilrat:
i may overlooked proposals for this case, if any please give
a link, sorry for possible duplicate topic.
This proposal was discussed two or three times in past, it
makes
On Monday, 19 May 2014 at 09:26:23 UTC, qznc wrote:
On Monday, 19 May 2014 at 08:20:54 UTC, Namespace wrote:
On Sunday, 18 May 2014 at 22:29:04 UTC, bearophile wrote:
"Undefined Behavior in C++; what is it, and why should I
care":
https://github.com/boostcon/cppnow_presentations_2014/blob/mast
On Monday, 19 May 2014 at 10:17:16 UTC, Jonathan M Davis via
Digitalmars-d wrote:
C++ is in the same situation with regards to its references,
and it works
fine. However, folks do often use pointers instead of
references in C++ in
order to make it clearer, and you're free to the same in D if
On Monday, 19 May 2014 at 09:56:38 UTC, bearophile wrote:
evilrat:
i may overlooked proposals for this case, if any please give a
link, sorry for possible duplicate topic.
This proposal was discussed two or three times in past, it
makes the D code look a little worse (beside being a breaking
On Mon, 19 May 2014 09:34:48 +
evilrat via Digitalmars-d wrote:
> as topic says sometimes ref has a 'little' problem now, it is
> unavoidable in some cases and has some readability in code and
> much more...
>
> imagine we have a function "void getMyNumber(ref int number)"
> which assigns 42
evilrat:
i may overlooked proposals for this case, if any please give a
link, sorry for possible duplicate topic.
This proposal was discussed two or three times in past, it makes
the D code look a little worse (beside being a breaking change if
you want require the ref at the calling point).
as topic says sometimes ref has a 'little' problem now, it is
unavoidable in some cases and has some readability in code and
much more...
imagine we have a function "void getMyNumber(ref int number)"
which assigns 42 to 'number', now lets look at C# code first:
--- C# code --
On Monday, 19 May 2014 at 08:20:54 UTC, Namespace wrote:
On Sunday, 18 May 2014 at 22:29:04 UTC, bearophile wrote:
"Undefined Behavior in C++; what is it, and why should I
care":
https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/Undefined-Behavior.pdf?raw=true
This reminds
On Mon, 19 May 2014 07:37:55 +
via Digitalmars-d wrote:
> On Monday, 19 May 2014 at 06:30:46 UTC, Jonathan M Davis via
> Digitalmars-d wrote:
> > makes dealing with immutable far, far more pleasant. It's
> > particularly useful
> > when you need to allocate an immutable object but also need t
Namespace:
dmd is right, so ldc has probably a bug.
I think D specs don't yet require a defined behaviour for that
code, so I think both outputs are correct.
Bye,
bearophile
On Sunday, 18 May 2014 at 18:03:26 UTC, bearophile wrote:
Some more slides pack from "C++ Now 2014":
"Undefined Behavior in C++; what is it, and why should I care":
https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/Undefined-Behavior.pdf?raw=true
This reminds us to remove a
On Sunday, 18 May 2014 at 22:29:04 UTC, bearophile wrote:
"Undefined Behavior in C++; what is it, and why should I care":
https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/Undefined-Behavior.pdf?raw=true
This reminds us to remove as much undefined behavior as
possible from
On Monday, 19 May 2014 at 06:30:46 UTC, Jonathan M Davis via
Digitalmars-d wrote:
makes dealing with immutable far, far more pleasant. It's
particularly useful
when you need to allocate an immutable object but also need to
mutate it as
part of initializing it. If you do it in a pure function whe
On Sunday, 18 May 2014 at 19:57:34 UTC, Walter Bright wrote:
The "_monitor" slot is also used for std.signals. It's been set
up in druntime to support more than just being a monitor.
We've also considered it for a hook for a reference count
(though that design had other problems).
I'm not sa
61 matches
Mail list logo
