On 2016-10-12 03:22, lobo wrote:
Hi,
I'm coming from C++ and wondered if the pattern below has an equivalent
in D using structs. I could just use classes and leave it up to the
caller to use scoped! as well but I'm not sure how that will play out
when others start using my lib.
Thanks,
lobo
m
On 2016-10-12 04:33, lobo wrote:
This approach works nicely although it feels clumsy but that's probably
just because I'm so used to C++. It also handles private members as I'd
expect, i.e. they're not accessible outside module scope through the
alias struct instance, but there is no protected.
On Sunday, 9 October 2016 at 14:06:42 UTC, Antonio Corbi wrote:
1. Inheritance with contracts is evaluated in a special way,
'in contracts' in the base and derived method (property) are
or-ed, so if one of them passses, the contract is believed to
have succeeded. As you don't have a contract in
On Wednesday, 12 October 2016 at 02:18:47 UTC, TheFlyingFiddle
wrote:
On Wednesday, 12 October 2016 at 01:22:04 UTC, lobo wrote:
Hi,
I'm coming from C++ and wondered if the pattern below has an
equivalent in D using structs. I could just use classes and
leave it up to the caller to use scoped
On Wednesday, 12 October 2016 at 02:18:47 UTC, TheFlyingFiddle
wrote:
void foo(ref ABase base)
{
base.ival = 32;
}
This should be:
void foo(ref Base1 base)
{
base.ival = 32;
}
On Wednesday, 12 October 2016 at 01:22:04 UTC, lobo wrote:
Hi,
I'm coming from C++ and wondered if the pattern below has an
equivalent in D using structs. I could just use classes and
leave it up to the caller to use scoped! as well but I'm not
sure how that will play out when others start us
Hi,
I'm coming from C++ and wondered if the pattern below has an
equivalent in D using structs. I could just use classes and leave
it up to the caller to use scoped! as well but I'm not sure how
that will play out when others start using my lib.
Thanks,
lobo
module A;
class Base1 {
in
I have a class T with a templated function foo(string name)(int,
int, float) that will be mixed in via template, and I want to
determine if that class has mixed it in such that foo(name =
"bar"). How could I go about this? Thanks.
eg:
mixin template A(string name, Args...) {
void foo(stri
On Tuesday, 11 October 2016 at 19:46:31 UTC, Jon Degenhardt wrote:
On Tuesday, 11 October 2016 at 18:18:41 UTC, ag0aep6g wrote:
On 10/11/2016 06:24 AM, Jon Degenhardt wrote:
The example I gave uses ref parameters. On the surface it
would seem
reasonable to that passing a static array by ref wou
On Tuesday, 11 October 2016 at 18:18:41 UTC, ag0aep6g wrote:
On 10/11/2016 06:24 AM, Jon Degenhardt wrote:
The example I gave uses ref parameters. On the surface it
would seem
reasonable to that passing a static array by ref would allow
it to be
modified, without having to slice it first.
Yo
On Tuesday, October 11, 2016 10:42:42 Ali Çehreli via Digitalmars-d-learn
wrote:
> Those interfaces already exist in Phobos: :)
>
>https://dlang.org/phobos/std_range_interfaces.html
>
> auto foo(int[] ints) {
>import std.range;
>if (ints.length > 10) {
>return
> cast(RandomAcce
On Tuesday, 11 October 2016 at 18:09:26 UTC, ag0aep6g wrote:
You've got some options:
Wow, thanks everyone, great information! I think I understand my
options now.
On 10/11/2016 06:24 AM, Jon Degenhardt wrote:
The example I gave uses ref parameters. On the surface it would seem
reasonable to that passing a static array by ref would allow it to be
modified, without having to slice it first.
Your ref parameters are only for the per-element operations. You'r
On 10/11/2016 09:55 AM, orip wrote:
auto foo(int[] ints) {
import std.range;
if (ints.length > 10) {
return chain(ints[0..5], ints[8..$]);
} else {
//return ints; // Error: mismatched function return type inference
of int[] and Result
return chain(ints[0..0], ints[0..$]); // Thi
On Tuesday, October 11, 2016 07:55:36 orip via Digitalmars-d-learn wrote:
> I get "Error: mismatched function return type inference" errors
> with choosing the return type for functions that work on ranges
> using, e.g, std.algorithm or std.range functions, but have
> different behavior based on ru
On 10/11/2016 10:28 AM, TheFlyingFiddle wrote:
On Tuesday, 11 October 2016 at 15:46:20 UTC, orip wrote:
On Tuesday, 11 October 2016 at 13:06:37 UTC, pineapple wrote:
Rewrite `return chain(ints[0..5], ints[8..$]);` as `return ints[0..5]
~ ints[8..$];`
The `chain` function doesn't return an arra
On Tuesday, 11 October 2016 at 15:46:20 UTC, orip wrote:
On Tuesday, 11 October 2016 at 13:06:37 UTC, pineapple wrote:
Rewrite `return chain(ints[0..5], ints[8..$]);` as `return
ints[0..5] ~ ints[8..$];`
The `chain` function doesn't return an array, it returns a
lazily-evaluated sequence of a
On Monday, 3 October 2016 at 09:06:32 UTC, Dicebot wrote:
Purpose is to skip code generation and only do syntax/semantic
validation. Very helpful when testing compiler because:
a) it takes less time speeding up overall test suite
b) doesn't require runtime static library to succeed, thus
simp
11.10.2016 18:46, orip пишет:
On Tuesday, 11 October 2016 at 13:06:37 UTC, pineapple wrote:
Rewrite `return chain(ints[0..5], ints[8..$]);` as `return ints[0..5]
~ ints[8..$];`
The `chain` function doesn't return an array, it returns a
lazily-evaluated sequence of an entirely different type fro
On Tuesday, 11 October 2016 at 13:06:37 UTC, pineapple wrote:
Rewrite `return chain(ints[0..5], ints[8..$]);` as `return
ints[0..5] ~ ints[8..$];`
The `chain` function doesn't return an array, it returns a
lazily-evaluated sequence of an entirely different type from
`int[]`.
Of course it do
On Tuesday, October 11, 2016 10:08:02 Nordlöw via Digitalmars-d-learn wrote:
> I can't find any traits `hasIndexing!R` corresponding to
> `std.range.primitives.hasSlicing!R`
>
> that is `true` iff `R` has `opIndex[size_t]` defined. Is there
> one?
>
> If not what should I use instead?
The traits i
On Monday, 10 October 2016 at 21:12:42 UTC, Martin Lundgren wrote:
So what's been happening in memory management land lately? Bad
GC seems like one of the Dlangs weak points, so showing
improvements here could definitely bring more people in.
It's not that the D GC is bad per se, but rather th
On Tuesday, 11 October 2016 at 07:55:36 UTC, orip wrote:
I get "Error: mismatched function return type inference" errors
with choosing the return type for functions that work on ranges
using, e.g, std.algorithm or std.range functions, but have
different behavior based on runtime values. The ret
On Tuesday, 11 October 2016 at 10:08:02 UTC, Nordlöw wrote:
I can't find any traits `hasIndexing!R` corresponding to
`std.range.primitives.hasSlicing!R`
My definition of `hasIndexing` so far:
https://github.com/nordlow/phobos-next/blob/master/src/typecons_ex.d#L83
I can't find any traits `hasIndexing!R` corresponding to
`std.range.primitives.hasSlicing!R`
that is `true` iff `R` has `opIndex[size_t]` defined. Is there
one?
If not what should I use instead?
I get "Error: mismatched function return type inference" errors
with choosing the return type for functions that work on ranges
using, e.g, std.algorithm or std.range functions, but have
different behavior based on runtime values. The return type is
always a range with the same underlying type.
26 matches
Mail list logo
