Nested Arguments Not Compiling

Nested arguments not compiling

PEP 3113 explains why this feature, "tuple parameter unpacking", was removed in Python 3. It also explains how to port code that uses them. In this case you'd need to change a function like:

def add(self, (sub, pred, obj)):
    self._addToIndex(self._spo, sub, pred, obj)
    self._addToIndex(self._pos, pred, obj, sub)
    self._addToIndex(self._osp, obj, sub, pred)

to a version which passes the tuple as a single parameter and unpacks it manually:

def add(self, sub_pred_obj):
    sub, pred, obj = sub_pred_obj
    self._addToIndex(self._spo, sub, pred, obj)
    self._addToIndex(self._pos, pred, obj, sub)
    self._addToIndex(self._osp, obj, sub, pred)

For a lambda function, you can't use assignment to unpack. The best solution there is usually to not unpack. For example, change this:

lambda (x, y): (y, x)

… to this:

lambda xy: (xy[1], xy[0])

For complicated functions, this can get ugly—but then for complicated functions, you probably want to def them anyway.

It's worth noting that running your code through 2to3, modernize, or futurize will find this problem in both def and lambda, and suggest exactly these solutions:

$ echo 'lambda (x,y): (y,x)' | 2to3 -
--- <stdin> (original)
+++ <stdin> (refactored)
@@ -1 +1 @@
-lambda (x,y): (y,x)
+lambda x_y: (x_y[1],x_y[0])

$ echo -e 'def foo((x,y)):\n    return (y,x)\n' | 2to3 -
--- <stdin> (original)
+++ <stdin> (refactored)
@@ -1 +1 @@
-def foo((x,y)):
+def foo(xxx_todo_changeme):
+    (x,y) = xxx_todo_changeme

If you're trying to port Python 2.x code to 3.x (or to dual-version code) and don't know both languages, you almost certainly want to use one of these tools—or an IDE plugin that wraps them—to help. (Although you may not want to use its output as-is.)

multiple nested wildcard - arguments not applicable

The following compiles as expected:

    List<Set<? extends Set<?>>> list = new ArrayList<Set<? extends Set<?>>>();
    list.add(new HashSet<Set<String>>());
    list.add(new HashSet<Set<Integer>>());

The problem is that generics is type invariant.

Consider the simpler example:

Given that there is a casting conversion from Animal to Dog (e.g. Dog extends Animal)...
- A List<Animal> IS NOT a List<Dog>
There is a capture conversion from List<? extends Animal> to a List<Dog>

Now here's what happens in this scenario:

Given that there is a capture conversion from Set<?> to Set<String>...
- A Set<Set<?>> IS NOT a Set<Set<String>>
There is a capture conversion from Set<? extends Set<?>> to Set<Set<String>>

So if you want a List<T> where you can add a Set<Set<String>>, Set<Set<Integer>>, etc, then T is NOT Set<Set<?>>, but rather Set<? extends Set<?>>.

Error in nested template argument when compile c++ in unix

Pre-C++11, nested template arguments had to have a space between the two closing angle brackets:

map<string, vector<string> >
//                    here^

C++11 allows you to omit that space. If you're stuck with C++03, just make sure you follow that particular syntax rule.

`requires` expression is evaluated to false in a nested template, but code is still compiled

I think the compilers are not implementing this correctly and you are correct that it should fail to compile.

In [temp.names]/7 it says that a template-id formed from a template template parameter with constraints must satisfy these constraints if all template arguments are non-dependent.

You are giving Wrapper only one argument, namely int which is not dependent. Therefore the compiler should check whether Wrapper<int> satisfies the constraint requires(false) of Wrapper. This check should fail.

I am not completely sure that requires(false) specifically is not IFNDR, because there are some similar rules forbidding e.g. templates which can never be instantiated, but the compilers seem to behave the same way if a non-trivial constraint is used.

Clang complains that the requires clause is a syntax error in that position, but I don't see any reason for that.

MSVC actually handles for example the following variation using a type constraint instead of a requires-clause as expected:

template<
    template<std::same_as<float> T>
    typename Wrapper>
using Test = Wrapper<int>;

but does not reject as expected if a requires-clause is used:

template<
    template<typename T>
    requires std::same_as<float, T>
    typename Wrapper>
using Test = Wrapper<int>;

Interestingly Clang crashes with an ICE on the former.

Code's not compiling because of nested anonymous blocks?

You appear to be linking against 2, or more, object files (or .a files) that define the same things. If you link against one or the other your linker problem will go away.

Nested Generics: Why can't the compiler infer the type arguments in this case?

Because the algorithm as described in the C# specification doesn’t succeed in this case. Let’s look at the specification in order to see why this is.

The algorithm description is long and complicated, so I’ll heavily abbreviate this.

The relevant types mentioned in the algorithm have the following values for you:

Eᵢ = the anonymous lambda (Foo x) => (Bar y) => new Baz()
Tᵢ = the parameter type (Func<T1, Func<T2, T3>>)
Xᵢ = the three generic type parameters (T1, T2, T3)

Firstly, there’s the first phase, which in your case does only one thing:

7.5.2.1 The first phase

For each of the method arguments Eᵢ (in your case, there’s only one, the lambda):

If Eᵢ is an anonymous function [it is], an explicit parameter type inference (§7.5.2.7) is made from Eᵢ to Tᵢ

Otherwise, [not relevant]

Otherwise, [not relevant]

Otherwise, no inference is made for this argument.

I’ll skip the details of the explicit parameter type inference here; it suffices to say that for the call G((Foo x) => (Bar y) => new Baz()), it infers that T1 = Foo.

Then comes the second phase, which is effectively a loop that tries to narrow down the type of each generic type parameter until it either finds all of them or gives up. The one important bullet point is the last one:

7.5.2.2 The second phase

The second phase proceeds as follows:

[...]

Otherwise, for all arguments Eᵢ with corresponding parameter type Tᵢ where the output types (§7.5.2.4) contain unfixed type variables Xj but the input types (§7.5.2.3) do not, an output type inference (§7.5.2.6) is made from Eᵢ to Tᵢ. Then the second phase is repeated.

[Translated and applied to your case, this means:

Otherwise, if the return type of the delegate (i.e. Func<T2,T3>) contains an as yet undetermined type variable (it does) but its parameter types (i.e. T1) do not (they do not, we already know that T1 = Foo), an output type inference (§7.5.2.6) is made.]

The output type inference now proceeds as follows; again, only one bullet point is relevant, this time it’s the first one:

7.5.2.6 Output type inferences

An output type inference is made from an expression E to a type T in the following way:

If E is an anonymous function [it is] with inferred return type U (§7.5.2.12) and T is a delegate type or expression tree type with return type Tb, then a lower-bound inference (§7.5.2.9) is made from U to Tb.

Otherwise, [rest snipped]

The “inferred return type” U is the anonymous lambda (Bar y) => new Baz() and Tb is Func<T2,T3>. Cue lower-bound inference.

I don’t think I need to quote the entire lower-bound inference algorithm now (it’s long); it is enough to say that it doesn’t mention anonymous functions. It takes care of inheritance relationships, interface implementations, array covariance, interface and delegate co-/contravariance, ... but not lambdas. Therefore, its last bullet point applies:

Otherwise, no inferences are made.

Then we come back to the second phase, which gives up because no inferences have been made for T2 and T3.

Moral of the story: the type inference algorithm is not recursive with lambdas. It can only infer types from the parameter and return types of the outer lambda, not lambdas nested inside of it. Only lower-bound inference is recursive (so that it can take nested generic constructions like List<Tuple<List<T1>, T2>> apart) but neither output type inferences (§7.5.2.6) nor explicit parameter type inferences (§7.5.2.7) are recursive and are never applied to inner lambdas.

Addendum

When you add a call to that identify function I:

G((Foo x) => I((Bar y) => new Baz()));

then type inference is first applied to the call to I, which results in I’s return type being inferred as Func<Bar, Baz>. Then the “inferred return type” U of the outer lambda is the delegate type Func<Bar, Baz> and Tb is Func<T2, T3>. Thus lower-bound inference will succeed because it will be faced with two explicit delegate types (Func<Bar, Baz> and Func<T2, T3>) but no anonymous functions/lambdas. This is why the identify function makes it succeed.

Nested macro with variadic arguments does compile in GCC but not in MSVC

My investigation makes me believe this is a bug in MSVC.

If I change the code to the following and do a pre-process to file (note that my 'coord' and 'variableName', 'otherVariableName' identifiers are just to make those parts of your code match something, and note how I have reversed your IF_BODY and IF_BODY_ and that IF_BODY_ is commented out by the #if 0):

#include <boost/preprocessor/repeat.hpp>

struct coord
{
    int latitude, longitude;
};

# define ESC_(...) __VA_ARGS__
#define ESC(vars) ESC_ vars

#if 0
# define IF_BODY_(n, condition, lhs, rhs, arg1, arg2) \
if (condition > n) { \
    lhs##n.arg1 = rhs[n].arg1; \
lhs##n.arg2 = rhs[n].arg2; \
}
#endif

# define IF_BODY(A, B) IF_BODY_(A, ESC(B))

# define IF_QUERY(z, n, vars) IF_BODY(n, vars)

int main()
{
    int index;
    coord variableName0, otherVariableName0;
    coord variableName1, otherVariableName1;
    coord variableName1, otherVariableName1;
    BOOST_PP_REPEAT(3, IF_QUERY, (index, variableName, otherVariableName, latitude, longitude))
}

I get the following:

int main()
{
    int index;
    coord variableName0, otherVariableName0;
    coord variableName1, otherVariableName1;
    coord variableName1, otherVariableName1;
    IF_BODY_(0, index, variableName, otherVariableName, latitude, longitude)
    IF_BODY_(1, index, variableName, otherVariableName, latitude, longitude)
    IF_BODY_(2, index, variableName, otherVariableName, latitude, longitude)
}

Note that the macro call has the correct number of arguments. However, if I change the #if 0 to #if 1 I get the following compiler output:
tester\tester.cpp(35): warning C4003: not enough arguments for function-like macro invocation 'IF_BODY_'

Looking at the preprocessed results in that case:

int main()
{
    int index;
    coord variableName0, otherVariableName0;
    coord variableName1, otherVariableName1;
    coord variableName1, otherVariableName1;
    if (index, variableName, otherVariableName, latitude, longitude > 0) { 0. = [0].; 0. = [0].; } 
    if (index, variableName, otherVariableName, latitude, longitude > 1) { 1. = [1].; 1. = [1].; } 
    if (index, variableName, otherVariableName, latitude, longitude > 2) { 2. = [2].; 2. = [2].; }
}

It seems that MSVC performs the macro variable assignment before performing the ESC expansion, that all of the contents of B get assigned to 'condition' rather than being broken out to the correct IF_BODY_ arguments. I will be submitting this as feedback through the MSVS Help -> Send Feedback -> Report a problem mechanism.

Okay, I have managed to find a solution but it is very ugly. It requires a variadic extension to the BOOST_PP_REPEAT family (which I have only partly implemented here). It may be worth submitting this as a suggestion to boost but I am not sure that boost.preprocessor is still maintained. And note how the ESC_/ESC macros are simply gone in this version.

#include <boost/preprocessor/repeat.hpp>

# define BOOST_PP_REPEAT_1_1_V(m, d, ...) m(2, 0, d, __VA_ARGS__)
# define BOOST_PP_REPEAT_1_2_V(m, d, ...) BOOST_PP_REPEAT_1_1_V(m, d, __VA_ARGS__) m(2, 1, d, __VA_ARGS__)
# define BOOST_PP_REPEAT_1_3_V(m, d, ...) BOOST_PP_REPEAT_1_2_V(m, d, __VA_ARGS__) m(2, 2, d, __VA_ARGS__)
# define BOOST_PP_REPEAT_1_4_V(m, d, ...) BOOST_PP_REPEAT_1_3_V(m, d, __VA_ARGS__) m(2, 3, d, __VA_ARGS__)
# define BOOST_PP_REPEAT_1_I_V(c, m, d, ...) BOOST_PP_REPEAT_1_ ## c##_V(m, d, __VA_ARGS__)
# define BOOST_PP_REPEAT_1_V(c, m, d, ...) BOOST_PP_REPEAT_1_I_V(c, m, d, __VA_ARGS__)

#define BOOST_PP_REPEAT_V BOOST_PP_CAT(BOOST_PP_CAT(BOOST_PP_REPEAT_, BOOST_PP_AUTO_REC(BOOST_PP_REPEAT_P, 4)), _V)

struct coord
{
    int latitude, longitude;
};

#if 1
# define IF_BODY_(n, condition, lhs, rhs, arg1, arg2) \
if (condition > n) { \
    lhs##n.arg1 = rhs[n].arg1; \
lhs##n.arg2 = rhs[n].arg2; \
}
#endif

#define ESC_(...) __VA_ARGS__
#define ESC(a) ESC_(a)
#define IF_BODY(a, ...) ESC_(IF_BODY_(a, __VA_ARGS__))
# define IF_QUERY(z, n, ...) IF_BODY(n, __VA_ARGS__)

int main()
{
    int index = 0;
    coord variableName0, variableName1, variableName2;
    coord otherVariableName[3];

    BOOST_PP_REPEAT_V(3, IF_QUERY, index, variableName, otherVariableName, latitude, longitude)
}

the new code expands to:

int main()
{
    int index = 0;
    coord variableName0, variableName1, variableName2;
    coord otherVariableName[3];

    if (index > 0) { variableName0.latitude = otherVariableName[0].latitude; variableName0.longitude = otherVariableName[0].longitude; } 
    if (index > 1) { variableName1.latitude = otherVariableName[1].latitude; variableName1.longitude = otherVariableName[1].longitude; } 
    if (index > 2) { variableName2.latitude = otherVariableName[2].latitude; variableName2.longitude = otherVariableName[2].longitude; }
}

Batch script not processing input parameter to nested batch file

cmd /k vcvarsall.bat x86_amd64 < crosscompile.bat x64

This means: start a cmd instance with the input stream redirected from the file (the file in disk, not the execution of) crosscompile.bat and the arguments to the cmd instance are the rest of the line, that is, /k vcvars.bat x86_amd64 x64

It is a lot easier to do

cmd /k " "vcvarsall.bat" x86_amd64 & "crosscompile.bat" x64"

Initialize variables, and then call the compile bat.

edited this is the command line i use for testing.

"%comspec%" /k " "c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 & "c:\testvc.bat" x86"

Nested Navigation in React Native not compiling

You are calling useNavigation before you define NavigationContainer, that should not work.
Make component, for example <AppNavigator /> as a children of NavigationContainer, then try to build your navigation in that component.

export default function App() {
  return (
    <NavigationContainer>
      <AppNavigator />
    </NavigationContainer>
  )
}

And your NavigationContainer is also fairly confusing to me.
So you either can have screens in your parent navigator or another navigators.

this is CORRECT:

<Drawer.Screen name="Home" component={HomeScreen} />

I would rename this, as you are trying to have StackNavigator here:

<Drawer.Screen name="One Step" component={OneStepScreen} />

to something like this example:

<Drawer.Screen name="One Step" component={OneSctepStack} />

And then in OneStepStack(former oneStepScreen) you can't have normal JSX mixed with Stack.Navigator.

function OneStepStack(){
  return(
            <Stack.Navigator>
                <Stack.Screen name="One Step Details" component={OneStepDetail} />
            </Stack.Navigator>
  );
}

Nested Arguments Not Compiling