In that example you could make opOpAssign take a "const ref" and
then the compiler could see that it could not return that
parameter, but this is slightly hacky and I can see how there may
be obscure corner cases where the rules are not sufficient.
Actually this could also be solved by using
So no more returning ref? Because if you allow returning ref,
you lose any notion of safety, unless you plan on changing the
entire compilation model?
The rules from DIP25/35 show how you can return refs while still
maintaining safety.
No it is not the only difference. "scope ref" (as proposed in
DIP35) is more restrictive in usage - can't take address of it,
can't return it, can't implicitly cast it to normal ref. It is
"scope" primarily and "rvalue ref solution" only secondarily.
With DIP25 these restrictions apply to "ref
I'd still like someone to explain how exactly "scope ref" would
differ from "ref" if DIP25/DIP35 were implemented.
If the only difference is that "scope ref" can accept rvalues
then why would you ever use normal "ref"? There are no extra
restrictions needed on "scope ref" over and above normal
'scope ref' would allow, that both, lvalues AND rvalues can be
bound to. DIP 35 don't say anything about that.
Just to be clear:
The primary reason at all DIP 36 was created, was in general to
find a possibility that accept rvalues AND lvalues. That was
the initial reason.
I understand th
I like this except for the proposed "addressOf" function from
DIP25 which is massively overkill. The safe-ness of & on a ref
should be determined by the compiler, so that initially it could
be unsafe but that could be relaxed when the compiler can
determine that the pointer does not escape. Syn
On Monday, 22 April 2013 at 13:17:36 UTC, Namespace wrote:
On Monday, 22 April 2013 at 12:22:14 UTC, Diggory wrote:
I realise I'm new here but this seems to be suggesting a whole
load of changes and special cases for something that can be
done in (IMHO) a much simpler way:
Why not s
I realise I'm new here but this seems to be suggesting a whole
load of changes and special cases for something that can be done
in (IMHO) a much simpler way:
Why not simply make escaping a "ref" pointer an unsafe operation.
The compiler should be able to detect this and report it without
any
Ah I didn't see that board, could a moderator move this please?
The problem is that neither "derelict" or "deimos" define a
specific "windows" binding. "deimos" has some parts of the
windows api in "wintypes.d" but it conflicts with the built in
windows api.
When importing under an alias, as
I'm new to D, and I'm trying to port a very small win32 opengl
app (~100 lines) from C++ to D but the bindings just don't seem
up to it...
Firstly a significant portion of wingdi.h seems to be missing
from the default windows bindings which come with phobos, enough
to make initialising an ope
101 - 110 of 110 matches
Mail list logo
